Sabem uma empresa pequenininha, chamada Correios, já ouviram falar? Só tem uma agência no mínimo em quase todas as cidades do Brasil. Conhecem? Hehehehe
O frontend deles é em Swing 
Esses dias vi outra empresa grande rodando Swing, mas não lembro qual foi. Eu sempre fico olhando os PDVs :D:D:D
[]´s
É culpa do Deitel rs.
[]s
Trabalhei 3 anos com Swing. Realmente é muito ruim, nada funciona por default e vc precisa saber como implementar muita coisa, utilizando muito Padrão de Projeto, o que dificulta a vida do iniciante. Estou trabalhando há um ano e meio com AIR (Desktop do Adobe Flex) e nunca mais quero saber de Swing. Java só como backend mesmo. O único problema foi que fiz curso de Flex em SP, pois não tinha em São José dos Campos. Mas isso agora até é uma coisa boa, pois estou abrindo meu próprio curso de Flex/Java em sjc…hehe.
Fora que o Swing é feio demais.
Só gostaria de deixar claro que essa opinião é pessoa, nada contra os amantes de Swing…rs.
[]s
[quote=Luiz Aguiar]É culpa do Deitel rs.
[]s[/quote]
Isso é vdd mesmo, maldito Deitel…rs
Veja eu estou desenvolvendo um ERP completo em SWING, é claro que estou estruturando de forma que possa expandí-la se necessário para WEB de maneira que aproveite toda a estrutura que não seja interface com o usuário. Como venho dos tempos em que se programava em character, não vejo dificuldades em se trabalhar com SWING.
Nossa. É o mesmo que exigir que se programe em Java 1.2… e ainda suportando a MS VM.[/quote]
Oi,
Nem me fala… estou desenvolvendo uma aplicação para Bematech, (para rodar na maquina FIT) no qual contem uma kvm integrada apenas com suporte a Java 1.3
Estou morrendo! Literalmente.
Tchauzin!
Apenas para testar!
Nos últimos 3 anos trabalhei em projetos com Swing e foi por exigência do cliente. Agora estou em outra empresa e também tem projetos em Swing pois utilizamos um ERP que só tem versão desktop. Eu particularmente gosto de trabalhar com essa interface 
Eu trabalhava no Lehman Brothers e o Lehman eh (ou ERA melhor dizendo 
) uma empresa que investia pesado no Java.
Acho que quase todos os sistemas que nos tinhamos la, tanto USA, Europa e Asia, era tudo Swing e os usuarios abriam o sistema atraves do Webstart.
Mas eu acredito mesmo que aplicacoes web sejam maioria pra Java ate pelo monte de frameworks que tem por ai que facilitam muito o desenvolvimento. Infelizmente a unica linguagem orientada a objeto que eu aprendi na faculdade (a muito tempo atras) foi o C++, entao eu nao sei se o pessoal aprende mais web ou desktop swing.
//Daniel
Eu odeio Swing! Odeio porque odeio programar em Desktop. Talvez eu já tenha falado isso antes: em sempre programei em servidor, seja o mais tradicional aplicativo web, seja um ouvinte socket de dados binários. E a coisa que eu mais odeio em programar pra Desktop é que as plataformas não chegam a ter separação entre conteúdo, formatação e manipulação de tela, como tem na Web. É graças a essa separação que bons aplicativos web conseguem ter uma estética que aplicações Desktop não chegam a ter.
Acredito que a preferência de alguns programadores por Desktop seja apenas cultural. O “mindset” sobre Desktop foi a primeira coisa que a maioria aprendeu, e muitos não conseguem (ou não querem) mudar de paradigma quando precisam encarar novos ambientes. É uma pena! Porque o mercado abarrota os crédulos por Desktop com ferramentas de arrasta-e-solta que escondem o essencial que existem em paradigmas diferentes (ex.: web ou mobile), tornando mais difícil qualquer resolução de problemas (principalmente relacionados a “gargalos”, como muito consumo de memória ou demora na execução).
Não entendi. Como assim não tem separação entre conteúdo, formatação e manipulação de tela? No desktop você modela as classes de negócio e a maioria das APIs desktop moderna, comunica-se com as telas através de models e uma camada de controle. E isso inclui o Swing. A diferença é apenas que a camada de controle é mais simples, já que a aplicação não fica distribuída numa rede, e a tela é uma forma confiável de validação de muitos dados.
É claro que existem maus programadores desktop. Que irão implementar lógica de negócio no meio dos actionListeners de botão. Bom, isso é tão má prática quanto escrever lógica de negócio dentro dos JSPs…
Mas não é à toa que vivo insistindo para os programadores Swing aqui aprenderem como o Swing funciona. Por que ele implementa o modelo MVC.
Para muitos tipos de sistema (inclusive os SAPs), até concordo com você.
Entretanto, se o software exige um controle um pouquinho mais aprofundado do hardware, a web passa a tornar-se uma péssima alternativa. Nós, por exemplo, tinhamos um software que enviava mensagens via socket para um servidor, que o usuário escolhia.
Esse servidor controlava um equipamento, ligado em centrais telefônicas. Não era incomum um laboratório ter 2 ou 3 equipamentos desses. A aplicação então rodava testes e dava resultados em tempo real, com atrasos máximos tolerados na casa dos milissegundos.
Não sei, mas parece que transformar essa arquitetura em web seria uma grande idiotisse. Primeiro, porque cada cliente era, por si só, bastante autônomo. Não vejo muito por que concentra-los todos num único servidor web. Depois, não vejo como enviar pacotes de rede pelo cliente. Isso teria que ser feito no servidor, o que criaria um gargalo descenessário.
Sem falar que as respostas do hardware deveriam ser pintadas na tela, em forma gráfica e em tempo real. Com javascript até é possível fazer isso, mas não sem pooling e com muito menos eficiência do que fazíamos.
Outro caso são jogos, softwares de pintura, navegadores, aplicativos que gerenciam recursos no SO, e muitos outros tipo de software que não se resumam a cadastro/relatório. O desktop tem seu nicho, menor que o web, mas onde ele sempre será necessário.
Agora, o importante é não ficar criando “paixões”. Programar web ou desktop é uma questão de necessidade. Ambas as tecnologias são ferramentas a nossa disposição. Basta identificar a situação em que cada uma é mais adequada que outra.
Oi,
Utilizo Swing hoje porque minha empresa desenvolve software para Desktop. Se um dia precisar utilizar WEB ou desenvolver programas para Celular (Como surgiu uma necessidade agora), irei fazer.
Não vejo dificuldade nenhuma. Apenas estudando conseguirei bons métodos e boas praticas.
Leonardo3001, discordo de tudo que você falou. Não preciso dizer mais nada, pois o Vini já disse tudo.
Tchauzin!
Vamos ao exemplo prático:
Web:
Desktop:
Outro exemplo:
1- O cliente pede que não seja exibido 10 campos de entrada, apenas 5 são necessários, o resto será preenchido no banco com valores default.
Programador web:
Programador Desktop:
2- O cliente pede que a cor da barra de cima seja azul, e não vermelho.
Programador web:
Programador Desktop:
Só pra clarear, o MVC é útil para separar o modelo da apresentação, mas este padrão não diz como é estruturado a View por si só. Na web, eu separo a visualização entre apresentação e conteúdo (usando CSS e HTML). No Desktop, não dá, a apresentação e o conteúdo é uma coisa só, tudo misturado. O problema é que o “mindset” Desktop não deixa ninguém considerar essa questão.
[quote=ViniGodoy]Entretanto, se o software exige um controle um pouquinho mais aprofundado do hardware, a web passa a tornar-se uma péssima alternativa. Nós, por exemplo, tinhamos um software que enviava mensagens via socket para um servidor, que o usuário escolhia.
Esse servidor controlava um equipamento, ligado em centrais telefônicas. Não era incomum um laboratório ter 2 ou 3 equipamentos desses. A aplicação então rodava testes e dava resultados em tempo real, com atrasos máximos tolerados na casa dos milissegundos.
Não sei, mas parece que transformar essa arquitetura em web seria uma grande idiotisse. Primeiro, porque cada cliente era, por si só, bastante autônomo. Não vejo muito por que concentra-los todos num único servidor web. Depois, não vejo como enviar pacotes de rede pelo cliente. Isso teria que ser feito no servidor, o que criaria um gargalo descenessário.
Sem falar que as respostas do hardware deveriam ser pintadas na tela, em forma gráfica e em tempo real. Com javascript até é possível fazer isso, mas não sem pooling e com muito menos eficiência do que fazíamos.
Outro caso são jogos, softwares de pintura, navegadores, aplicativos que gerenciam recursos no SO, e muitos outros tipo de software que não se resumam a cadastro/relatório. O desktop tem seu nicho, menor que o web, mas onde ele sempre será necessário.[/quote]
Eu acredito na lei de Atwood:
E a medida que o tempo passa, mais e mais tipos de aplicações passam a serem viáveis na Web. O seu exemplo pode ser considerado onde o Desktop era a melhor alternativa. Mas isso quando? Em 2007? Em 2010?
Vamos extrapolar: e se sua aplicação fosse requerida em 2019? Ainda acha que Desktop seria melhor que a Web? Veja, enquanto você descrevia o problema, eu imaginava como faria usando HTML5 e WebSockets. Algo impensável de se fazer hoje (dada a falta de disponibilidade no IE), mas que pode ser viável no futuro.
O Desktop tem seu nicho (e usaria se fosse necessário), mas é muito menor do que o pessoal pensa.
Sim, eu tenho minhas paixões. Mas eu não sou idiota. As minhas escolhas são baseadas em experiência, não em “press release” de vendors. E posso tranquilamente mudar de opinião, havendo bons argumentos.
Eu vejo isso como uma vantagem
Vamos ao exemplo prático:
Web:
Desktop:
Ué, só por que a plataforma por si só já oferece tudo que é necessario significa que é ruim?
Horas, a tecnologia evolui, talvez o HTML 5 até resolva esses problemas, mas até agora, o Desktop resolveu, caso a web realmente evolua para fazer isso com certeza as pessoas poderam migrar felizes para essa solução.
E voce só apresentou argumentos para sistemas cadastro/relatorio, que normalmente é o que a web faz.
Nosso sistema não controlava só o servidor socket. Ele também interoperava com dispositivos em portas seriais, conexões USB e com dispositivos de entrada diferentes, como leitores de dados. Orquestrava as coisas através de scripts e permitia que o próprio cliente extendesse funcionalidade com suas próprias bibliotecas. Era uma espécie de Rich Client para execução de testes telefônicos.
Mas concordo com você, Leonardo, numa coisa. A parte de modelar uma interface gráfica da web é mais interessante mesmo. Eu gostaria de ter algo como css para o Swing.
Isso não é necessariamente uma tecnologia web, embora tenha surgido nos browsers, mas sim, a arquitetura da API gráfica, que essencialmente roda no cliente, mesmo no caso da web. Uma aplicação desktop poderia trabalhar dessa forma (de fato, o dicionário Aurélio Eletrônico que temos aqui, é uma aplicação desktop que usa o componente gráfico do browser para renderizar suas telas), e nem por isso deixaria de ser desktop.
Seria muito interessante ter uma API que permitisse o layout num css, mas tratasse eventos como cliques em links ou botões da forma que o desktop já faz hoje. E tivesse nos componentes renderizados a flexibilidade que temos hoje para formatos e coisas do tipo. Algumas APIs novas, como o JavaFX, já implementam alguns conceitos desse tipo, embora ainda timidamente.
Vamos aí para uma pergunta mais fundamental: O que diferencia uma aplicação desktop de uma aplicação web? Não é o fato de usar TCP/IP e ser cliente/servidor. Se for assim, boa parte das aplicações desktop hoje já é web, afinal, o próprio MySQL roda sobre TCP/IP. Nem o fato de ser distribuída, ou aplicações usando RMI seriam aplicações web. Nem mesmo fato de usar o navegador, se fosse assim, uma página estática seria uma aplicação web.
O que me parece fazer mais sentido seria o fato da aplicação web ser projetada para rodar numa rede de baixo tempo de resposta. E daí toda a idéia por trás do servidor que faz post-back e response, sem conexão. Agora, essa realidade de tempos de resposta absurdos também está mudando para a internet. E daí, a necessidade de cada vez mais interatividade no cliente e de existirem websockets, que já trabalhem com um modelo duplex, orientado a conexão.
O que eu quero dizer com isso? Que no futuro, não vejo muita diferença entre uma aplicação desktop e uma aplicação web. Me parece claro que ambas convergem para a mesma coisa, e é até mesmo difícil dizer qual delas prevalecerá. A medida que os scripts de cliente ganham mais poder, e mais capacidades interativas, surgem para eles mais bibliotecas com necessidades do desktop. Ao mesmo tempo, os tempos de resposta tendem a ser cada vez menores, e a largura de banda cada vez maior, o que aproxima a internet de uma rede interna.
Eu acredito que conceitos de ambos serão incorporados dos dois lados, e os mundos se fundirão. A forma de fazer aplicações de hoje irá mudar um pouco, e provavelmente o novo modelo irá gradualmente substituir tanto as atuais aplicações web, quanto as desktop.
Eu deveria ter perguntado isso aqui quando comecei com Java, eu era um Desktop Lover nato
Pessoalmente curto muito aplicações desktop e Java Swing, agora JavaFX (pela facilidade =D).
Acredito que Java Swing seja ensinado nas escolas pois é simples em questões arquiteturais. Vamos treinar Java usando Java EE, daí vem filter, web server, HTML/CSS/Javascript… Isso complica o ensino de Java, IMHO. Swing é programar, compilar e tals.
Fiz uma só aplicação comercial com Java Swing. Fábricas, Strategy, Builder, eu era um formal em OO, bons tempos… Hoje não tenho mais a oportunidade de trabalhar com Java Swing, que pena :’(
Quanto a briga Desktop X WEB. Desenvolvimento Desktop tem chão ainda… HTML5 é bonito e tals, WEB é bem portável, mas desktop se destaca como o envolvimento maior com o hardware.
Um ponto que acredito que seja mais opinião minha é a manutenção. Um sistema Desktop é muito mais fácil de manter e ter especialistas, enquanto WEB precisamos de mais caras. Mas só minha opinião
O que sera que o Desktop fez pra ele ter tanta revolta?rsrsrs
Na minha humilde opinião de iniciante,quem ta na chuva é pra se molhar,se é programador então é programador seja web,desktop,java,vb ou sei la OQ.
Concordo com a Lina se for preciso mudar,é só estudar.Tive uma proposta para trabalhar com Genexus,em uma semana já tinha aprendido o suficiente
pra me virar sozinha,era novo e bem estranho,mas nada que dedicação e estudo não resolva.
Calma,tadinho do Desktop!
Já ouviram a expressão: “Jack of all trades, master of none.”?
Como a tecnologia Web usa linguagens diferentes, cada uma pode evoluir para o seu propósito específico.
Outra, o Vinny mostrou que precisava acessar portas seriais no cliente. Então, é claro que a opção Web estaria fora. (Havia imaginado que o hardware estava “espetado” no servidor, e que o acesso era remoto.) Não descarto uma tecnologia que eu não gosto quando esta é a melhor alternativa técnica.
Porém, dando pra fazer pela Web, eu faço. Minha restrição é a falta de DSLs específicas pra formatação e apresentação em praticamente todas as plataformas Desktop. Tenho uma teoria do porquê dessa ausência: as APIs são projetadas primeiramente para uma IDE drag’n’drop, não para o programador. Se desse pra fazer clientes ricos simples apenas usando VIM, quem compraria IDEs?
Vamos combinar: uma aplicação sem interface gráfica, pra ser executado via Crontab ou por administradores de sistemas não é Desktop, é BATCH.
Tirando esses casos, eu uso tanto Web quanto Desktop para… cadastro e relatório!
Desculpa, mas as duas palavras “cadastro” e “relatório” servem pra classificar tudo aquilo que aplicações gráficas fazem. Posso até mesmo dizer que jogos também são aplicações de “cadastro” e “relatório”: “cadastro” são todos os movimentos que eu desejo que o personagem do jogo faça, e “relatório”, todas as movimentações dos meus inimigos e do meu personagem.
Enfim, não leve tão ao pé-da-letra. É só pra dizer que isso não invalida minha argumentação.