Você começa a migrar seu projeto Swing para JavaFX [fechado]

Eu tenho um projeto de 4 anos que está escrito em Swing + SwingX. Atualmente, ele ainda está vivo e continua chutando.

No entanto, à medida que mais solicitações de recursos relacionados à GUI são recebidas (por exemplo, uma tabela em árvore classificável), começo a sentir a dificuldade de atender às solicitações. Isso é verdade especialmente porque não há nenhum desenvolvimento ativo em torno do projeto SwingX.

Além disso, dificilmente consigo encontrar uma estrutura Java GUI boa, mas mantida / desenvolvida / em evolução ativa.

Eu estava pensando, algum dos desenvolvedores do Swing sente a mesma coisa? Você começou a migrar seu projeto Swing para uma estrutura de GUI desenvolvida muito mais ativa, como JavaFX?

Pessoalmente, estou migrando para o JavaFX (2.1+, não a versão antiga e estranha 1.x com a linguagem desagradável de script). O novo JavaFX não é 100% perfeito, mas já é uma visão muito mais agradável de usar do que o Swing, vejo um futuro razoável para ele (especialmente considerando o mecanismo incorporado do Webkit).

Eu me pergunto a mesma coisa frequentemente, mas acho que não migraria os projetos existentes para o JavaFX. Pelo menos não por enquanto, e não para projetos de médio e grande porte. No entanto, eu consideraria o JavaFX para novos projetos e consideraria uma migração novamente no futuro e reavaliaria a pergunta com base no progresso do JavaFX.

No momento, minhas preocupações são:

• Imaturidade

  Sim, vamos para o 3.0 em breve, mas ainda não existe há muito tempo e ainda passamos por grandes mudanças. Portanto, para softwares corporativos grandes e avessos ao risco, esse é um ponto relativamente dolorido.

• atuação

  Não vi dados suficientes sobre diferenças de desempenho.

• Widgets e componentes

  Não vi ganhos suficientes nos novos componentes. Isso pode estar relacionado à imaturidade, eu acho. Também não sei ainda o quão bem eles podem ser estendidos e compostos, em contraste com o Swing.

No geral, acho que faltam dados concretos sobre as vantagens para me convencer totalmente do JavaFX.

Por outro lado, o Swing é comprovado e testado. Sim, a API é desajeitada e invocar a conclusão automática no IDE em um objeto Swing como o JTextPane fará com que ela chore e chore por sua mãe, mas, se você tiver conhecimento suficiente, poderá criar interfaces de usuário impressionantes com o Swing, que estão com bom desempenho (nunca comprei a falácia do Swing-tem-mau desempenho, consulte as postagens anteriores de Romain Guy nos blogs da Sun) e permitem que você faça coisas bem legais.

Portanto, antes de mudar qualquer coisa, recomendo que você tente primeiro um pequeno protótipo e talvez tente portar algumas das caixas de diálogo do aplicativo e ver como ele funciona.

Eu tenho feito muito JavaFX agora e prefiro o Swing. A estrutura do Gráfico de cena é diferente da que você está acostumado com o Swing, mas oferece muitas melhorias. É divertido trabalhar com a API, parece refrescante.

Você pode fazer muito mais com isso, multimídia, animação, navegação na web. Você pode, por exemplo, criar um aplicativo do Google Maps em algumas linhas de código, incorporando html5 e javascript.

Diz-se que está incluído no tempo de execução do Java 8, o que significaria como a substituição definitiva do Swing como a estrutura da interface do usuário padrão

@ Migração : você deve começar isolando partes do seu aplicativo que podem ser convertidas em JavaFX. A interoperabilidade do Swing-JavaFX 2 é importante, você pode usar o javafx.embed.swing.JFXPanel para incorporar seu elemento JavaFX. Consulte interoperabilidade swing-fx . (Para completar, você também pode incorporar no SWT.)

Swing está se tornando uma tecnologia legada, ou já é. No entanto, é muito bom no que faz e não vai desaparecer em um futuro previsível, por isso não vejo razão para me afastar, especialmente se alguém já investiu nele. O JIDE Software produz bons componentes Swing (comerciais) para substituir o que está faltando no Swing padrão. Por exemplo, treetable classificável está em suas grades fora da caixa.

Embora as novas versões do JavaFX pareçam impressionantes, duvido que valha a pena fazer uma migração completa, a menos que você esteja disposto a investir muito tempo / esforço / dinheiro em uma revisão completa da GUI.

Swing pode ter suas peculiaridades e está mostrando sua idade, mas também tem algumas vantagens:

• Capacidade de plataforma cruzada muito forte, atualmente muito melhor que JavaFX
• É maduro e comprovado, muito mais que o JavaFX
• Possui um grande ecossistema de comunidade / biblioteca de usuários
• Você provavelmente já tem muitas habilidades de Swing ou pode contratar pessoas facilmente com elas

Por fim, se não estiver quebrado, por que corrigi-lo?

Obviamente, para um novo projeto, eu estaria olhando seriamente para JavaFX, Android e / ou uma GUI baseada na Web (talvez com algo como Vaadin).

Estou na mesma posição que o OP - tendo aplicativos de swing herdados, mas precisando implementar novos idiomas e interfaces que ele não suporta nativamente. O maior desses aplicativos foi refatorado algumas vezes por vários motivos (melhorar a modularidade, melhor MVC e estrutura de envio de eventos etc.), portanto, não sou totalmente avesso a reescrever o código da interface do usuário. Então, eu pensei muito sobre o assunto.

No entanto, algumas coisas não podem ser resolvidas com o Swing sem investir muito mais tempo e esforço no que é essencialmente uma tecnologia herdada. Por exemplo, exceto eventos simples do mouse, novos dispositivos de tela de toque e não são suportados pelo próprio Swing. Fornecer um componente de navegador baseado em Swing é igualmente problemático ou caro e, no meu caso, a abordagem javafx-in-swing não é uma opção, pois complica o tratamento de eventos da interface do usuário de maneiras não triviais.

Eu acho que tem sido o velho e fiel em seu tempo, e se sua plataforma é tão imutável quanto sua base de código - fique com ela, obviamente. Mas, para que um aplicativo avance para novos casos de uso mais contemporâneos, o JavaFX 2+ provavelmente será o caminho a seguir no meu caso.

Como uma observação lateral: a única falha no Swing que eu adoraria ter desaparecido no jfx - mas não o fez - é a abordagem de um thread para regra de todos eles no envio de eventos da interface do usuário. Qualquer interface de usuário não trivial precisa de multi-threading para manter a interface do usuário nítida e responsiva, e deixar inteiramente ao desenvolvedor de aplicativos tropeçar nas mesmas armadilhas com tanta facilidade é um déficit no API IMHO.

Eu tive uma ótima experiência usando o RCP em aplicativos grandes para desktop. Ele basicamente começou como uma abstração da camada GUI do Eclipse e percorreu um longo caminho desde então. Em vez de Swing, que é baseado no AWT, o RCP se baseia no JFace, que por sua vez é baseado no SWT. Permite desenvolver aplicativos e usar os conceitos da GUI que o próprio Eclipse usa (visualizações, editores, perspectivas, assistentes, etc.). É muito escalável e, como o próprio Eclipse, está sendo aprimorado constantemente.

No entanto, nunca migrei um projeto existente do Swing para o RCP; Eu imagino que levaria um bom tempo para entender seus diferentes paradigmas e, se você não separou seu modelo e visualizou as camadas, é provável que tenha dificuldades. Mas desde que você perguntou sobre coisas como tabelas de árvores classificáveis, o RCP é ótimo nisso.

Se você quiser reler isso ainda mais, experimente o tutorial de Lars Vogel ou dê uma olhada em alguns exemplos de projetos de código aberto ou comerciais que usam o RCP.

(Por exemplo, uma tabela em árvore classificável), começo a sentir dificuldade em atender às solicitações. Isso é verdade, especialmente não há desenvolvimento ativo em torno do projeto SwingX.

• não é verdade, novamente este projeto está vivo,

• blablabla uma vez quando o SwingX perdeu as concessões da Sun (durante a aquisição pela Oracle) os povos do SwingX criaram o JavaFX

Além disso, dificilmente consigo encontrar algo de bom, ainda sendo ativamente mantido / desenvolvido / evoluindo a estrutura Java da GUI.

• no Swing não é sobre Framework, mas sobre Look and Feel

• As estruturas são para usuários não técnicos (MsAccess é pode ser o melhor exemplo para a GUI Framework)

• mas se você deseja criar um aplicativo real, também possui fortes conhecimentos sobre o Swing e substituiu o Framework,

• exemplo engraçado O Netbeans construiu o Swing Framework com base no JSR296, mas não é possível alterar o ícone JFrames diretamente,

Você começou a migrar seu projeto Swing para uma estrutura de GUI desenvolvida muito mais ativa como o JavaFX?

sem razão

• mesmo com a migração para o Java7, talvez quando haverá o Java7.15 - 17

• Estou comparando o JavaFx com o Nimbus, o desenvolvimento terminou / desistiu em algum lugar no primeiro semestre

• desculpe, eu não sou desenvolvedor, sou apenas Java & Swing Fan