Quali fattori considerare quando si sceglie il runtime / la lingua per le applicazioni desktop Windows?

Tutti i miei utenti hanno Windows. Alcuni usano Linux o un Mac, ma se lo fanno sono generalmente in grado di usare qualcosa come Mono, Wine, Parallels o dual-boot.

Il mio team di sviluppo (incluso me stesso) ha una vasta esperienza sia nella scrittura di applicazioni Swing in Java sia in Windows Form in C #. "Ampio" significa che abbiamo sviluppato e spedito oltre tre applicazioni in entrambi i tempi di esecuzione. Le applicazioni sono applicazioni di analisi tecnica, così lievi sull'interazione del database, ma pesanti sull'interfaccia utente personalizzata e sulle dimensioni dei set di dati.

Stiamo arrivando al punto in cui vogliamo davvero prendere una decisione su quale piattaforma su cui concentrarci da ora in poi, poiché sta diventando un peso per supportare entrambi (se lavori in Swing per sei mesi è troppo seccante) per abituarci di nuovo a Windows Form e viceversa) e vogliamo che tutti i membri del nostro team siano in grado di lavorare su tutte le nostre applicazioni.

• Windows Form richiede generalmente meno lavoro per rendere riconoscibili le applicazioni Windows. Nessuna quantità di skin e controlli personalizzati in Java ha risolto questo problema nel corso degli anni. Allo stesso tempo, non abbiamo mai avuto un cliente che non potesse usare le applicazioni Swing.
• Java aveva un ecosistema molto più ricco in termini di librerie e strumenti di compilazione automatizzati, ma questo sta cambiando rapidamente (Java non sta andando giù, è più che .NET sta recuperando terreno).
• Nel raro caso in cui si preferisca la multipiattaforma, Java batte .NET a mani basse. Mono è meraviglioso, ma è ancora più lavoro di Java.

Se scegliamo .NET possiamo iniziare a concentrarci su WPF, ma anche iniziare a usare F #. Se scegliamo Java, possiamo iniziare a concentrarci su RCP, ma anche iniziare a usare Scala.

Qualcuno ha dovuto prendere una decisione simile? In tal caso, cos'è stato e cosa ti ha influenzato di più? Qualche preoccupazione principale mi manca?

(Nota: ci sono già domande simili su Programmers.SE, ma non sono costruttive o da una prospettiva diversa.)

Abbiamo scelto Java (Swing) e alcune parti native tramite JNI. Mentre la domanda commerciale di multipiattaforma può essere marginale oggi, la situazione potrebbe essere diversa in 5 anni e il ciclo di vita dell'app (un'app di misurazione scientifica) sarà più simile a 10+ anni (il suo predecessore C ++, ancora usato oggi, ha file sorgente datati 1991). Come hai scritto, Java batte NET in maniera diretta in ambienti non Windows e, se mai avessimo bisogno di passare da Windows, è solo una questione di ricompilare alcune parti native, magari perfezionare l'aspetto della GUI e verificare che tutto funziona.

Se sei sicuro che sarai solo Windows e la tua app vivrà solo pochi anni, allora .NET potrebbe essere preferito: sembra e si comporta più come un'app nativa perché lo è. Ma come investimento a lungo termine mi fido di più di Java. L'altalena può sembrare un po 'meno che perfetta, il tempo di avvio potrebbe essere più lungo, tutto è un po' subottimale a causa del livello di astrazione multipiattaforma, ma almeno "funziona".

Una cosa che potresti prendere in considerazione è il progetto IKVM che ti consente di usare il codice Java in un mondo .NET. È quindi possibile ottenere i vantaggi di un backend Java, mentre - per quanto ne so - è possibile avere un frontlayer sottile in Swing o WinForms.

http://www.ikvm.net/

Ho sentito che altri l'hanno usato per usare una libreria di connessioni open source scritta in Java da .NET invece di dover usare la ingombrante versione di .NET.

C'è una risorsa su MSDN che potrebbe esserti utile: http://msdn.microsoft.com/en-us/gg715299.aspx .

Se vai in fondo alla pagina troverai un sacco di white paper che confrontano concettualmente Java e .NET. Ovviamente dato che è su MSDN è distorto verso .NET, ma le risorse sono ancora abbastanza utili.

Ho pensato anche a questo e ho trovato che la risposta dipende dal tipo di progetto e da cosa puoi prevedere al riguardo.

A volte, la creazione di One Codebase per servire tutte le piattaforme è una buona cosa: ottieni un certo livello di coerenza dell'interfaccia utente con meno codice complessivo. Penso che i vantaggi e gli svantaggi siano ovvi, quindi lo salterò.

Ci sono momenti in cui è meglio avere 2 basi di codice scritte in modo nativo. Se, ad esempio, scrivere l'app in WPF è elegante per .NET e scriverla, diciamo, Cocoa è elegante per Mac OS, il codice risultante potrebbe effettivamente essere più piccolo dell'uso, diciamo, Java o Mono (che non ha WPF). In tal caso, potresti ottenere risultati migliori con meno codice.

Un'ultima considerazione sta forse facendo la tua app come un'applicazione HTML5 o persino un'estensione di Chrome, ma potrebbe essere un campo troppo a sinistra.

Hai considerato Silverlight ? Può essere una buona scelta per compilare anche l'applicazione Desktop di Windows (da SL4 +) e funzionare bene su Mac.

Come sviluppatore Java a tempo pieno posso dirti che mentre la compatibilità multipiattaforma è sorprendente, ogni integrazione nativa è un inferno .

Ho sempre avuto molti problemi, e talvolta fallito, per questo motivo. Potresti non averne bisogno, ma a volte ci inciampo e di solito fa male.

• L'integrazione con COM è dolorosa e COM + è talvolta impossibile (settimane sprecate nel tentativo di farlo funzionare con l'API Tablet Windows).
• L'interazione hardware può danneggiare. A volte l'API è disponibile solo su una piattaforma (ad es. Integrazione fotocamera / scanner).
• Anche l'interazione con le applicazioni locali può danneggiare. Ho già detto quel dolore COM? Bene, un altro modo (che abbiamo effettivamente utilizzato) è stato quello di generare ed eseguire script VBS che avviino un'applicazione Windows come MapPoint o alcune app di mappatura proprietarie e le forniscano dati.
• Anche l'installazione e l'integrazione desktop (collegamenti, programma di disinstallazione, menu di avvio) possono danneggiare. L'avvio Web non è affidabile. Le alternative ti costano caro o mancano alcune funzionalità (come la distribuzione degli aggiornamenti).

Non fraintendetemi. Sono uno sviluppatore Java e non intendo infiammarlo. Sto solo dicendo che se sospetti di aver bisogno di uno di questi, può far male e potresti stare meglio con .net . Almeno è un argomento che dovresti prendere in considerazione.