Porque não usar java no desktop?

Programação Arquitetura
#41

A gente desenvolve com Java em Desktop aqui.

Eu acho bastante produtivo, desde que se tenha uma IDE. Usamos o GridBagLayout e essas coisas feias que o pessoal falou por aí. Somos auxiliados nesse sentido pelo VE, não usamos o GridBag na mão.

Mas certamente, não é um mar de rosas. O VE tem seus problemas, e o Swing tem uma curva de aprendizado gigantesca. Agora, acho um ponto positivo o fato de ser muitíssimo fácil de alterar o seu comportamento visual. Aqui temos tabelas que fazem auto-filtro, por exemplo.

Mas, já citando o Thingol, “o swing é mesmo meio esquizofrênico”. Algumas coisas que deveriam ser ridiculamente fáceis (bem citadas pelo Marcio, como definir um número máximo de caracteres ou só aceitar maiúculas) são complicadas de se fazer.

Preferir extender document do que mudar uma simples propriedade? Tá louco? Isso sim é gostar de sofrer…

Agora, a grande vantagem. Temos usuários em Linux e Windows. Em outra de nossas aplicações, usamos diversos protocolos de rede.

Ah sim, um idioma comum em aplicações desktop é praticamente impossível de se implementar automaticamente em java: gravar arquivos no diretório onde o binário da aplicação está. Você simplesmente não consegue obter essa informação no java!!! Não estou falando do diretório “.”. Esse aí, refere-se ao local onde o usuário configurou para abrir o aplicativo, não ao local real do binário.

#42

[color=darkblue]Até agora todos citaram como motivo a produtividade, Java para Desktop não é improdutivo, o que leva um usuário a decidir por uma ou outra solução ?

Ninguém até agora levou em consideração as soluções arquiteturais para Java para Desktop, se instalarmos em um cliente é necessário também instalar a JVM, sempre que há uma atualização como proceder ?

Se desenvolververmos uma solução distribuída, colocando em um servidor e “startando” a aplicação através do Java Web Start, dependendo do tamanho da aplicação toda vez que houver uma atualização tem uma lentidão inicial para incialização da aplicação.

A manutenção de sistema para Desktop em Java querendo ou não tem uma maior complexidade que um sistema similar em outras linguagens, em alguns casos levando mais tempo.

Ainda existem problemas no escopo e processo de desenvovimento, qual a melhor solução arquitetural, uma aplicação multi-thread ou mono-thread ?

Tenho pouco tempo de experiência e muito o que aprender ainda, mas já trabalhei com ERP em Swing, quando a aplicação inicia, um processo ou Thread inicia, dentro desse processo, se você abre uma tela para fazer um simples select no banco e não abre um sub-processo a tela simplesmente irá travar enquanto o usuário faz sua consulta.

Uma aplicação distribuída usando EJB rodando em um servidor, se há erros no dsenvolvimento elevando o processamento, quando para interrompe o processo de todos os outros clientes.

Até mesmo uma aplicação pequena em Java para Desktop pode exigir um grande processamento.

O que leva uma empresa a decidir por uma ou outra tecnologia não é somente a produtividade. [/color]

#43

Vini,

Você conhece:

getClass().getProtectionDomain().getCodeSource().getLocation()

? Não estou sendo irônico, apenas perguntando se com isso você não consegue resolver seu problema.

#44

Distribuí-la (sim, a JVM mesmo) via WebStart.

E com Delphi e VB você pretende atualizar a aplicação como? De qualquer forma, se você versionar os seus jars, o JWS consegue distribuir apenas o diff da sua aplicação. Aqui no cliente usamos essa solução e uma aplicação de 11 MB é atualizada com 100-200k em média.

#45

Bom dia.
Acima o Marcio Santri comentou uma coisa interessate a respeito de se defender tecnologias, na verdade minha inteção nunca foi defender uma liguagem ou tecnologia, minha questão é que hoje em dia com o advento do web2.0 utilizando ajax e milhares de linhas de javascript que quando dá pau, nem o firefox tem ferramenteas que me ajudem a resolver.
Pensando neste aspecto cheguei a conclusão que se desktop não for tão produtivo como web, talvês possa ter a mesma produtividade e a facilidade de integração em ferramentas. Então a comparação aqui é java x java. :smiley: .
Agora quanto ao post do metaleiro, vendo por cima o problema citado por ele, eu entendo que os problemas que ele teve foram arquiteturais e não relacionados a tecnologia e, com qualquer tecnologia, se o sistema não for bem arquitetado vai apresentar muitos problemas de performance e manutenção.
Cada vez mais eu vejo que usar java no desktop pode ser uma alternativa viavel em relação ao html+ajax.

#46

Distribuí-la (sim, a JVM mesmo) via WebStart.

E com Delphi e VB você pretende atualizar a aplicação como? De qualquer forma, se você versionar os seus jars, o JWS consegue distribuir apenas o diff da sua aplicação. Aqui no cliente usamos essa solução e uma aplicação de 11 MB é atualizada com 100-200k em média.[/quote]

[color=darkblue]

Sei que a aplicação pode ser distribuída, mas penso pelo seguinte, existem sistemas que eu não vejo porque ser implementado em Java, um exemplo:

Um sistema simples, de caixa, uma padaria ou uma locadora, você pode criar um simples executável em qualquer outra linguagem, para atualizá-lo o próprio usuário pode ir clicando em um setup.

Um sistema em Java, você tem que atualizar os .JAR, tem a instalação da JVM ou JRE, as vezes ocorre algum problema pela diferença com o ambiente de desenvolvimento.

A interface do sistema da padaria é muito boa, mesmo usando uma API em Java não vejo uma interface tão boa quanto a dos sistemas em outras linguagens.

Qualquer sistema para desktop pode também ser implementado em Java, mas eu não consideraria a melhor opção em muitos casos, gosto da linguagem, particularmente se fosse desenvolver qualquer coisa iria pensar em Java, mas um cliente não, talvez não veja vantagens em se utilizar Java.

Sei que existe a possibilidade de se criar executáveis em Java, mas ainda assim não vejo como a melhor opção.
[/color]

#47

[quote=Metaleiro]Um sistema simples, de caixa, uma padaria ou uma locadora, você pode criar um simples executável em qualquer outra linguagem, para atualizá-lo o próprio usuário pode ir clicando em um setup.

Um sistema em Java, você tem que atualizar os .JAR, tem a instalação da JVM ou JRE, as vezes ocorre algum problema pela diferença com o ambiente de desenvolvimento.[/quote]

Existem diversos softwares que geram instaladores para aplicações Java.

Nada impede que se tenha uma boa interface com Java.

Bem, isso é verdade. O fato é que numa situação dessas, a linguagem mais apropriada também é a que você domina mais, se for você que vai fazer o sistema.

Não estou aqui dizendo que o sistema da padaria que vai rodar numa máquina só deva ser feito cegamente em Java, mas eu ainda acredito que se você sabe Java, tem experiência com desenvolvimento desktop e não conhece Delphi/VB, talvez seja muito mais prático e rápido pra você fazer o sistema em Java nessas condições.

#48

[color=darkblue]

Devo estar parecendo pessimista quanto a tudo que disse, mas na verdade não é bem isso.

Quando comecei a trabalhar com Java entrei em um projeto de migração de um sistema antigo em Java Swing para Web, o sistema possuia os .JAR em um servidor e era “startado” por .BATs nos clientes, as .BATs também ficavam alocadas no Servidor eram criados atalhos nos clientes.

Todos os .JAR eram importados para os clientes e inicializados localmente, o sistema era multi-thread e foi feito na versão 1.1 do Java, cada vez que se abria uma janela dentro dele iniciava-se um novo processo, tudo o que disse até agora são coisas que os usuário reclamavam:

Java é pesado - Consumo de memória
Java é Lento - Má utilização de threads provocavam lentidão no sistema
Java é feio é quadrado - A interface do Java
Java Trava - Novamente threads e alguns casos conexões não eram fechadas com a base

Foi criado um sistema distribuído, rodava no servidor e os clientes acessavam via WebStart, dessa vez mono-thread, usando EJB, a interface apesar de semelhante era muito superior, a view também foi feita em Swing, apesar de partes dele estavam sendo migradas para Web, mas os usuários ainda reclamavam praticamente das mesmas coisas.

Sei que boas práticas de programação minimizam todos os problemas, podendo até anulá-los, mas sempre existem erros, as vezes também os cometo, estou sempre aprendendo também, acredito que são coisas do gênero que fazem com que Java não seja amplamente apreciado para Desktop.

O projeto de um sistema Java para Desktop tem que ser bem definido e estruturado, mas ainda assim acho que Java é a melhor opção, isso é claro dependendo do caso.

[/color]

#49

Beleza metaleiro.

Quanto a reclamações dos usuários mesmo que voce escreva sue sistema utilizando uma linguagem xyz, os usuários sempre vão reclamar dessas coisas: Pesado, lento, feio etc.
Isso é default dos usuários não importa a linguagem que desenvolva.
Agora quanto aos outros problemas observados, pela sua descrição. são arquiteturais e não culpa da linguagem.
Na verdade programas escritos em qualquer linguagem podem ter e terão problemas de arquitetura pois, nada é perfeito.
mas a questão é, se eu tiver com uma unica opção java, será que não é viável criar aplicações com swing do que com ajax?

#50

putz, depende muito… mas acho mais fácil isso que o contrário…

#51

Via de regra, construa sempre um sistema desktop quando não houver usuários esporádicos.

Ex: pra um Submarino da vida, seria ridículo esperar que o consumidor fizesse download duma aplicação desktop pra fazer os pedidos e visualizar os produtos. Ao mesmo tempo, nada impede o backend inteiro da loja de ser uma aplicação desktop.

#52

A Borland desenvolveu a Vcl.net que faz com que o visual e muitos objetos utilizados no Delphi Win32 sejam portáveis para a plataforma .net. Ficou legal mas eu não aconselharia o uso. Ele também pode ser desenvolvido utilizando a estrutura padrão do .net, assim como o Vb.Net e um monte de linguagens suportada por esta arquitetura. No entanto, creio que a linguagem mais indicada para ser utilizada nesta plataforma seja realmente o C#. Em um dos projetos que participei, em alguns casos que exigiam uma performance mais violenta recorríamos ao Delphi.Net por que ele ainda suportava o tipo “record”, que seria um vetor só que de tipos específicos. Achava até muito estranho o .net permitir isto… Criávamos uma classe para processamento (que ficava dentro de uma dll) e só.

#53

Permite sim, porque é mapeado para um tipo especial de classe (struct) que no C# requer um monte de metadata. Exemplo:

type Ponto = record
    x : real;
    y : real;
end;

seria mais ou menos, em C#:

using System.Runtime.InteropServices;
[StructLayout (LayoutKind.Sequential, Pack=4)]
public struct Ponto {
    public double x;
    public double y;
}

Aham, faz milhares de anos que não lido com Pascal, não sei se o Real do Pascal é o double ou o float do C#.

#54

Não conheço e vou testar! :slight_smile:

#55

[quote=thingol][quote]
Achava até muito estranho o .net permitir isto…
[/quote]

Permite sim, porque é mapeado para um tipo especial de classe (struct) que no C# requer um monte de metadata. Exemplo:

type Ponto = record
    x : real;
    y : real;
end;

seria mais ou menos, em C#:

using System.Runtime.InteropServices;
[StructLayout (LayoutKind.Sequential, Pack=4)]
public struct Ponto {
    public double x;
    public double y;
}

Aham, faz milhares de anos que não lido com Pascal, não sei se o Real do Pascal é o double ou o float do C#.
[/quote]

Morrendo e aprendendo, hehehe.
Confesso que essa do struct eu não sabia.
Obrigado.

#56

pelo o que vejo e que todos queria que existisse somente uma linguage a que eu gosto, sou desenvolvedor de sistemas tem 8 anos ja usei diversas ferramentas, desde boas ides ate editores como o kwrite e o gvim e sempre me adaptei ao que eu precisava fazer.

o que temos aqui é uma medo, o mesmo que os usuários dos nossos sistemas tem quando somos obrigados a mudar uma metodologia de negocio e eles não se adequão, mas a mudança tem que ser feita. o que temos aqui é um usuáio do delphi(ide, pascal linguage) que teve que, ou tentou, desenvolver uma aplicação java(linguagem) desktop e não usou uma IDE com com caracteristicas para este procedimento.

só para ambientar o colega, tente usar o netbeans 5.5.1 ou o eclipse com os plugins corretos e depois fale sobre a produtividade do java, mas antes tente se atualizar quanto a linguagem e metodos de desenvolvimento de projeto, aprender patherns e poo também e uma boa. ah outra coisa vcs estão falando mal do goias e ficou ate engraçado, aqui no tocantins o delphi caiu no desuso a onda aqui é PHP, Java/JSP e .NET mas este ultimo esta bem queimado devido a grande onda de invasão a servidores IIS.

#57

[quote=rodrigopmatias]pelo o que vejo e que todos queria que existisse somente uma linguage a que eu gosto, sou desenvolvedor de sistemas tem 8 anos ja usei diversas ferramentas, desde boas ides ate editores como o kwrite e o gvim e sempre me adaptei ao que eu precisava fazer.

o que temos aqui é uma medo, o mesmo que os usuários dos nossos sistemas tem quando somos obrigados a mudar uma metodologia de negocio e eles não se adequão, mas a mudança tem que ser feita. o que temos aqui é um usuáio do delphi(ide, pascal linguage) que teve que, ou tentou, desenvolver uma aplicação java(linguagem) desktop e não usou uma IDE com com caracteristicas para este procedimento.

só para ambientar o colega, tente usar o netbeans 5.5.1 ou o eclipse com os plugins corretos e depois fale sobre a produtividade do java, mas antes tente se atualizar quanto a linguagem e metodos de desenvolvimento de projeto, aprender patherns e poo também e uma boa. ah outra coisa vcs estão falando mal do goias e ficou ate engraçado, aqui no tocantins o delphi caiu no desuso a onda aqui é PHP, Java/JSP e .NET mas este ultimo esta bem queimado devido a grande onda de invasão a servidores IIS.[/quote]

Não sei se referia à minha pessoa, mas vamos lá.
Medo de trocar de plataforma, linguagem, etc… Programador que é assim fica preso no passado, não é nosso objeto. Isso serve para pessoas bitoladas SÓ em Java. Em 2 anos pretendemos abolir o Delphi por aqui. Daí nosso estudo extendido. Há 4 anos que estamos neste processo, é muito tempo para uma falsa má impressão.
Eu até entendo seu comentário, mas não é a realidade. Uso o NetBeans desde a versão 4.1, e sinceramente, este não é o motivo. Até o Visual Studio é melhor que o NetBeans para desenvolvimento Desktop, por exemplo.
Sobre Goiás, o pessoal de SP deve achar que a região metropolitana de Goiânia (Goiânia e cidades agregadas, com + de 2 milhões de habitantes) usa Clipper até hoje… Uma vez, num cliente em São José do Rio Preto, o cara me perguntou o que eu achava da cidade grande. Com gente assim, é melhor nem discutir. Mas uma coisa é verdade: goiano que programa em Java tem o costume de ir para Brasília. 200Km de distância e um salário bem maior. Passei uma temporada por lá (na verdade, sou de Brasília) e os salários são bem mais animadores.

#58

Eu nao tive dificuldade de abandonar o C++ builder para passar usar Netbeans com AbsoluteLayout foi muito tranquiloa a minha transição por isto nao entendo qual a dificuldade.

#59

A dificuldade está em se obter resultados tão bons com a mesma produtividade. Nossa telas têm muitas funcionalidades complexas e sofrem muitas alterações e implementações. Não, não são falhas de projeto, é o mercado. Como trabalhamos com muitas empresas, é comum algumas mudarem o processo de trabalho e temos que dar o suporte (e rápido!) para que isso ocorra. Apesar de trabalharmos apenas com um segmento, as requisições são muitas.
O AbsoluteLayout realmente é bem bacana. Mas ainda dá um trabalhinho principalmente de ficar movendo nossos objetos sozinhos quando no ambiente de desenvolvimento. Existem outros fatores que atrapalham a programação desktop no Java. Segurança, no nosso caso, foi um dos fatores que mais pesou. O fato de ser “descompilável” pesou bastante. Apesar dos ofuscadores, é possível localizar algoritmos de senha mensal (usamos isto) e outros dados importantes. Numa aplicação Delphi, isto é bem mais complexo. Já consegui fazer um desvio utilizando o Assembly, utlizando depuradores, mas não descobrir algoritmos de senha, etc.
Sei que cada caso é um caso. Talvez para o seu projeto tenha atendido bem. Mas, dependendo do caso, vários fatores devem ser ponderados.

#60

melhore seu programação usar certificados digitais para estes casos resolve o problema, e não importaria o quão bom o cara é para descobrir o algoritimo de cripto se ele não tem a semente, conhecida com chave privada.

o problema e que em muitos lugares ainda se usão artificios antigos e arcaicos. o pessoal do delphi ate hj não conseguiu resolver o problema com os timebomb para usar o delphi e o c++ builder trial pelo resto da vida.