Quais fatores a serem considerados ao escolher o tempo de execução / idioma para aplicativos da área de trabalho do Windows?

Todos os meus usuários têm Windows. Alguns deles usam Linux ou Mac, mas, se o fazem, geralmente são capazes de usar algo como Mono, Wine, Parallels ou inicialização dupla.

Minha equipe de desenvolvimento (inclusive eu) tem uma vasta experiência tanto na criação de aplicativos Swing em Java quanto em Windows Forms em C #. "Extensivo" significa que desenvolvemos e enviamos mais de três aplicativos em ambos os tempos de execução. Os aplicativos são aplicativos de análise técnica, tão leves na interação com o banco de dados, mas pesados ​​na UI personalizada e nos tamanhos de conjuntos de dados.

Estamos chegando ao ponto em que realmente queremos tomar uma decisão sobre qual plataforma focar a partir de agora, já que está se tornando um fardo para apoiar os dois (se você estiver trabalhando no Swing por meio ano, é muito complicado. se acostumar com o Windows Forms novamente e vice-versa) e queremos que todos da nossa equipe sejam capazes de trabalhar em todos os nossos aplicativos.

• O Windows Forms geralmente exige menos trabalho para criar aplicativos reconhecíveis do Windows. Nenhuma quantidade de controles personalizados e de aparência em Java resolveu isso ao longo dos anos. Ao mesmo tempo, nunca tivemos um cliente que não pudesse usar os aplicativos Swing.
• O Java costumava ter um ecossistema muito mais rico em termos de bibliotecas e ferramentas de construção automatizadas, mas isso está mudando rapidamente (o Java não diminui, é mais o que o .NET está atualizando).
• Para os raros casos em que a multiplataforma é preferida, o Java supera o .NET. Mono é maravilhoso, mas ainda é mais trabalhoso que Java.

Se escolhermos o .NET, podemos começar a focar no WPF, mas também começar a usar o F #. Se escolhermos Java, podemos começar a focar no RCP, mas também começar a usar o Scala.

Alguém já teve que tomar uma decisão semelhante? Se sim, o que foi e o que mais influenciou você? Alguma preocupação importante que estou perdendo?

(Observe: já existem algumas perguntas semelhantes sobre Programmers.SE, mas elas não são construtivas ou de um ângulo diferente.)

Fomos para Java (Swing) mais algumas partes nativas via JNI. Embora a demanda comercial por multiplataformas possa ser marginal hoje, a situação pode ser diferente em 5 anos, e o ciclo de vida do aplicativo (um aplicativo de medição científica) será mais de 10 anos (seu antecessor C ++, ainda usado hoje, arquivos de origem datados de 1991). Como você escreveu, o Java supera o .NET em ambientes não Windows, e se precisarmos mudar do Windows, é apenas uma questão de recompilar algumas partes nativas, talvez ajustando a aparência da GUI e verificando se tudo funciona.

Se você tem certeza de que será apenas Windows, e seu aplicativo permanecerá em vigor por apenas alguns anos, o .NET pode ser o preferido - ele se parece e se comporta mais como um aplicativo nativo porque é. Mas, como investimento de longo prazo, confio mais em Java. O balanço pode parecer um pouco menos que perfeito, o tempo de inicialização pode ser mais longo, tudo fica um pouco abaixo do ideal por causa da camada de abstração multiplataforma, mas pelo menos "simplesmente funciona".

Uma coisa que você pode querer considerar é o projeto IKVM, que permite usar o código Java em um mundo .NET. Você pode obter os benefícios de um back-end Java, enquanto - pelo que entendi - você pode ter um fino frontlayer no Swing ou no WinForms.

http://www.ikvm.net/

Ouvi dizer que outras pessoas usaram isso para usar uma biblioteca de conexão de código aberto escrita em Java do .NET em vez de precisar usar a versão pesada do .NET.

Há um recurso no MSDN que pode ser útil para você: http://msdn.microsoft.com/en-us/gg715299.aspx .

Se você for para o final da página, encontrará vários whitepapers que comparam Java e .NET conceitualmente. É claro que, como está no MSDN, é direcionado para o .NET, mas os recursos ainda são bastante úteis.

Também pensei nisso e descobri que a resposta depende do tipo de projeto e do que você pode prever.

Às vezes, é bom criar o One Codebase para atender a todas as plataformas - você obtém algum nível de consistência da interface do usuário com menos código geral. Eu acho que as vantagens e desvantagens são óbvias, então eu vou pular isso.

Há momentos em que ter duas bases de código escritas nativamente é melhor. Se, por exemplo, escrever seu aplicativo no WPF é elegante para .NET e, digamos, Cocoa é elegante para Mac OS, o código resultante pode ser menor do que usar, por exemplo, Java ou Mono (que não possui WPF). Nesse caso, você pode obter melhores resultados com menos código.

Uma consideração final é talvez fazer seu aplicativo como um aplicativo HTML5 ou mesmo uma extensão do Chrome, mas esse campo pode ficar muito a esquerda.

Você já considerou o Silverlight ? Pode ser uma boa opção para criar também o aplicativo Windows Desktop (do SL4 +) e funcionar bem no Mac.

Como desenvolvedor Java em tempo integral, posso lhe dizer que, embora a compatibilidade entre plataformas seja incrível, toda e qualquer integração nativa é um inferno .

Eu sempre tive muitos problemas, e às vezes falhei, nesse campo. Você pode não precisar, mas às vezes eu tropeço nela e geralmente dói.

• A integração com o COM é problemática e o COM + às vezes é impossível (semanas perdidas tentando fazê-lo funcionar com a API do Windows Tablet).
• A interação de hardware pode prejudicar. Às vezes, a API está disponível apenas em uma plataforma (por exemplo, integração de câmera / scanner).
• A interação com aplicativos locais também pode prejudicar. Eu mencionei essa dor COM? Bem, outra maneira (que realmente usamos) era gerar e executar scripts VBS que iniciam um aplicativo do Windows, como o MapPoint ou algum aplicativo de mapeamento proprietário, e o alimentam com dados.
• A instalação e a integração da área de trabalho (atalhos, desinstalador, menu Iniciar) também podem prejudicar. O Web Start não é confiável. As alternativas custam caro ou estão faltando alguns recursos (como a distribuição de atualizações).

Não me interpretem mal. Sou desenvolvedor de Java e não pretendo chamá-lo. Só estou dizendo que se você suspeitar que precisará de alguma das opções acima, isso pode doer e você pode se sair melhor com .net . Pelo menos é um argumento que você deve levar em consideração.