Alguém aqui usa Java + Swing para fazer programas comerciais?

ceklock:

Tenho uma dúvida em relação ao uso de Java + Swing: hoje em dia é viável programar em Java comercialmente fazendo programas voltados ao desktop usando Swing?

Alguém aqui trabalha em alguma empresa nessa área :?:

Se vc tem profissionais habilitados na equipe a trabalhar com Java e o cliente não tem nada contra qual o problema?

O problema é que só se vê vagas para programação JavaEE. Nada contra, mas surgiu essa dúvida. Talvez com o Java 7 as pessoas achem o Java menos lento. O Java 6 já melhorou bastante esse aspecto, mas muita gente ainda fala da lentidão do Java. E de fato, muitos programas desktop feitos em Java demoram muito para inicializar.

ceklock:

O problema é que só se vê vagas para programação JavaEE. Nada contra, mas surgiu essa dúvida. Talvez com o Java 7 as pessoas achem o Java menos lento. O Java 6 já melhorou bastante esse aspecto, mas muita gente ainda fala da lentidão do Java. E de fato, muitos programas desktop feitos em Java demoram muito para inicializar.

O grande problema do java no desktop é a pobre integração com o SO nativo e falta de profissionais dedicado a essa plataforma (comparado com outras tecnologias como Delphi e plataforma MS). Quanto a diferença de performance é praticamente insignificante na maioria das aplicacoes comerciais.

Eu uso Swing e acho o resultado satisfatório. O segredo penso eu está na sua arquitetura e na sua JTable.

É viável sim. O Swing é uma ferramenta confiável para o desenvolvimento de interfaces com o usuário. Desde que haja a separação correta entre a interface com o usuário, as regras de negócio e a persistência não há problema para o desenvolvimento de aplicativos comerciais sérios. Também, nada impede de utilizar juntamente as tecnologias JEE.

att.

Isto depende de uma série de fatores, como por exemplo uma aplicação que utiliza uma grande quantidade de recursos de banco de dados, ou uma arquitetura mau modelada. A quantidade de memória que a o java se usa no windows quando sua aplicação é executadao não muito diferente do que o .Net Framework tb utiliza.

Acontece que o java EE é o segmento java mais utilizado, pois é maduro e possui padrões em sua api que facilitam o desenvolvimento.

ceklock:

O problema é que só se vê vagas para programação JavaEE. Nada contra, mas surgiu essa dúvida. Talvez com o Java 7 as pessoas achem o Java menos lento. O Java 6 já melhorou bastante esse aspecto, mas muita gente ainda fala da lentidão do Java. E de fato, muitos programas desktop feitos em Java demoram muito para inicializar.

Essa demora para inicializar não se deve ao java deve-se aos programadores.
Em desktop vc tem que saber muito mais sobre java e OO do que em EE ou web. Não dá para fazer desktop com um bando de juniors… alguem precisa ter feito antes e saber das armadilhas.
Desktop é muito menos trivial que web ou EE mas é muito mais rico , “podre de rico” como se diz hoje. Vc consegue fazer qq coisa que imaginar em termos de ui. O problema é que com a pouca qualidade dos programadores em geral e a falta de frameworks web, é muito mais dificil.

Em web vc já tem o browser que cuida de todos os eventos do usuário , em desktop vc tem que programar tudo isso do zero.

sergiotaborda:

ceklock:

O problema é que só se vê vagas para programação JavaEE. Nada contra, mas surgiu essa dúvida. Talvez com o Java 7 as pessoas achem o Java menos lento. O Java 6 já melhorou bastante esse aspecto, mas muita gente ainda fala da lentidão do Java. E de fato, muitos programas desktop feitos em Java demoram muito para inicializar.

Essa demora para inicializar não se deve ao java deve-se aos programadores.
Em desktop vc tem que saber muito mais sobre java e OO do que em EE ou web. Não dá para fazer desktop com um bando de juniors… alguem precisa ter feito antes e saber das armadilhas.
Desktop é muito menos trivial que web ou EE mas é muito mais rico , “podre de rico” como se diz hoje. Vc consegue fazer qq coisa que imaginar em termos de ui. O problema é que com a pouca qualidade dos programadores em geral e a falta de frameworks web, é muito mais dificil.

Em web vc já tem o browser que cuida de todos os eventos do usuário , em desktop vc tem que programar tudo isso do zero.

Concordo com o que o sérgio disse, e acrescento que com as máquinas de hoje e com melhorias como o compilador JIT o swing não perde em nada para linguagens “nativas” como delphi e afins, talvez o que deixa o swing com cara de malvado é o fato de sua curva de aprendizado ser muito maior em relação com as opções do mercado e isso querendo ou não desanima as pessoas que pensam em migrar.

Mais ou menos… As vezes pode ser culpa do programador sim, mas grandes programas feitos em Java, como o Netbeans por exemplo, costumam ter uma demora maior para inicializar do que programas pré-compilados. Essa demora deve-se ao fato de ter que carregar a maquina virtual e todas as classes do programa, e fazer a compilação Just In Time. Mas fora isso concordo que é tranquilo, só que essa demora na inicializacao de programas maiores as vezes faz as pessoas ficarem com a impressão de que o Java é lento (só pra deixar claro, nunca achei o Java lento, só to falando isso pq é o q muita gente fala e eu não concordo).

http://en.wikipedia.org/wiki/Just-in-time_compilation

Eu usava Swing para fazer sistemas na indústria. Como boa parte deles dava feedbacks em tempo real, seria pouquíssimo viável fazer em web.

Olá

Só uma observação porque li uma frase sobre JTable que me deixou horrorizado… se bem que em 1999/2000 participei de sistemas em Java que acessavam a base de dados diretamente via rede local.

Swing serve para sistemas desktop. Só que sistema desktop não tem nada a a ver com aqueles sisteminhas isolados que antigamente no milênio passado a gente fazia em Clipper, VB o Delphi.

Desde 2001 que todos que me conhecem sabem que se o chinês da pastelaria da esquina contratar alguém para fazer um sisteminha de fluxo de caixa, um dia o Seu Ling Ching vai querer viajar para China e consultar o sistema de lá.

Então o que sempre fiz em todos os sistemas Swing que partipei depois que a Sun lançou os servlets, eram sistemas com camada de apresentação Swing porém acessando um servidor via UrlConnection (ou com ajuda de HttpClient) e no servidor instalava a base de dados.

Resumindo…

Não programe em Java o que em Clipper, VB ou Delphi ficaria muito melhor. Aproveito o que o Java tem de bom é fácil e use protocolo http para se comunicar.

[]s
Luca

É verdade. Temos que saber separar as diferentes camadas da aplicação para poder migrar de Swing pra Web sem maiores problemas.

Swing é apenas uma camada de apresentação.

Luca:

Olá

Só uma observação porque li uma frase sobre JTable que me deixou horrorizado… se bem que em 1999/2000 participei de sistemas em Java que acessavam a base de dados diretamente via rede local.

Swing serve para sistemas desktop. Só que sistema desktop não tem nada a a ver com aqueles sisteminhas isolados que antigamente no milênio passado a gente fazia em Clipper, VB o Delphi.

Desde 2001 que todos que me conhecem sabem que se o chinês da pastelaria da esquina contratar alguém para fazer um sisteminha de fluxo de caixa, um dia o Seu Ling Ching vai querer viajar para China e consultar o sistema de lá.

Então o que sempre fiz em todos os sistemas Swing que partipei depois que a Sun lançou os servlets, eram sistemas com camada de apresentação Swing porém acessando um servidor via UrlConnection (ou com ajuda de HttpClient) e no servidor instalava a base de dados.

Resumindo…

Não programe em Java o que em Clipper, VB ou Delphi ficaria muito melhor. Aproveito o que o Java tem de bom é fácil e use protocolo http para se comunicar.

[]s
Luca

Mais ou menos… As vezes pode ser culpa do programador sim, mas grandes programas feitos em Java, como o Netbeans por exemplo, costumam ter uma demora maior para inicializar do que programas pré-compilados. Essa demora deve-se ao fato de ter que carregar a maquina virtual e todas as classes do programa, e fazer a compilação Just In Time. Mas fora isso concordo que é tranquilo, só que essa demora na inicializacao de programas maiores as vezes faz as pessoas ficarem com a impressão de que o Java é lento (só pra deixar claro, nunca achei o Java lento, só to falando isso pq é o q muita gente fala e eu não concordo).

O problema do NetBeans não é o swing e sim o sistema de plugins. É a inicilização dos plugins que demora , não o swing. O mesmo acontece com o Eclipse que é SWT (supostamente é “nativo”) . Acontece porque o eclipse tb tem plugins.

Além disso o JIT é feito em paralelo , não consome tempo da aplicação.

Bom, que demora alguns microsegundos a mais pra inicializar é um fato, mas um operador de caixa de supermercado ou de banco não precisa abrir o aplicativo a cada cliente da fila, logo esse argumento não faz sentido para a maioria dos casos onde uma aplicacao desktop seria utilizada.

Sim, desenvolver interfaces não é pra qualquer um. Se tudo que vc fez na sua vida foi programar para containers web ou servidores de aplicação onde é inclusive recomendado não criar threads, fique sabendo que aplicações desktop são inerentemente multi-threads. E ai é que separamos os homens dos meninos.

Mais ou menos… As vezes pode ser culpa do programador sim, mas grandes programas feitos em Java, como o Netbeans por exemplo, costumam ter uma demora maior para inicializar do que programas pré-compilados. Essa demora deve-se ao fato de ter que carregar a maquina virtual e todas as classes do programa, e fazer a compilação Just In Time. Mas fora isso concordo que é tranquilo, só que essa demora na inicializacao de programas maiores as vezes faz as pessoas ficarem com a impressão de que o Java é lento (só pra deixar claro, nunca achei o Java lento, só to falando isso pq é o q muita gente fala e eu não concordo).

O problema do NetBeans não é o swing e sim o sistema de plugins. É a inicilização dos plugins que demora , não o swing. O mesmo acontece com o Eclipse que é SWT (supostamente é “nativo”) . Acontece porque o eclipse tb tem plugins.

Além disso o JIT é feito em paralelo , não consome tempo da aplicação.

Não sei não. O Eclipse parece bem mais leve que o Netbeans.

Inerentemente multi-threads? O que você quer dizer com isso?

Saber otimizar o código para múltiplas threads é bom, mas não é absolutamente necessário em aplicações desktop.

Inerentemente multi-threads? O que você quer dizer com isso?

Saber otimizar o código para múltiplas threads é bom, mas não é absolutamente necessário em aplicações desktop.

vc já leu algum tutorial básico de swing ou precisou fazer alguma coisa alem de uma tela simples?

A primeira lição que se aprende é toda atualização de tela precisa ser feito de uma thread específica, isso sem falar se vc precisar exibir animações, conectar com banco de dados ou um webservice, ou ainda ler arquivos, sem travar a tela.

Bom, não sei o que vc chama de “otimizar código para múltiplas threads” mas sem saber threads vc não vai muito longe em swing e outros frameworks, como Cocoa no mac.

Uso Swing há muito tempo, e com exceção do SwingUtilities.invokeLater() e algumas poucas animações feitas com o uso de threads, eu praticamente não uso threads no código.

Prefiro usar apenas quando há real necessidade, pois isso faz o código ficar mais difícil de manter. E real necessidade é quando tem algum código pesado a ser processado, que pode demorar para o usuário receber uma resposta.

Ah é? Me mostre o link do tutorial da Sun aonde está escrito isso.

Ah é? Me mostre o link do tutorial da Sun aonde está escrito isso.

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/SwingUtilities.html#invokeLater(java.lang.Runnable)

prefiro usar o SwingWorker

ceklock:

Uso Swing há muito tempo, e com exceção do SwingUtilities.invokeLater() e algumas poucas animações feitas com o uso de threads, eu praticamente não uso threads no código. Prefiro usar apenas quando há real necessidade, pois isso faz o código ficar mais difícil de manter.

Então só porque vc não tem new Thread() no seu código não esta usando threads? :shock:

O que eu quis dizer com Swing usar inerentemente threads é que, mesmo que voce não crie threads no seu código, vc precisa ser bom em threads para aproveitar o maximo do potencial do framework, ou simplesmente não fazer merda.

Fora software embarcado e software em tempo real, porque sistema desktop?

Minha opinião: A tendência é web então não é o java desktop que não tem força mas sim trabalhar com aplicativos que rodam direto na máquina.

vlw

Bird89du:

Fora software embarcado e software em tempo real, porque sistema desktop?

Minha opinião: A tendência é web então não é o java desktop que não tem força mas sim trabalhar com aplicativos que rodam direto na máquina.

vlw

Cara me desculpe, mas AONDE QUE VC VIU QUE A TENDENCIA É WEB?

todo mundo diz isso, só nunca vi ninguem dizer daonde tiraram isso. Foi das vagas de emprego em Java? Só se desenvolve desktop em Java?

O Mercado de Desktop está ai, e quem ficar nesse modinha de a tendencia é web, vai sair perdendo um excelente nicho de mercado.

Se teu cliente chegar e disse, eu quero desktop, vai vai dizer que web é tendencia? e vai dizer que não desenvolve?

Me desculpe mas tendencia é algo que nunca é bom de ser focado.

Rafael,

Eu realmente acho que vagas de emprego, solicitação de projetos e oportunidades para desenvolvimento são bons indicadores para definir uma tendência, podem não ser o método mais formal mas enfim muitas vezes são eficazes.

Se procurarmos na web, Tendencias de TI, veremos alguns sites e artigos indicando principalmente cloud computing.

Ressaltando, eu não quero dizer que Desktop não é mais usado nem nada assim apenas que Web é a tendência principalmente para aplicativos comerciais.

vlw

Hehe. Desenvolvimento web é tendência a mais de uma decada, seja lá o que isso vem a dizer. Eu pelo menos passei todo esse período ganhando a vida desenvolvendo aplicações nativas (tanto desktop quanto mobile) acessando web services rest.

Olá

Concordo, há muito mercado. Aliás eu mesmo sou forte usuário de aplicações desktop. No momento estou usando o Google Chrome mas uso outras como o Dropbox, Skype, Msn, etc.

O que desde o início deste milênio não vejo mais sentido é o modelo de aplicações isoladas ou confinadas em uma rede local. Me refiro àquelas em que o Swing acessa a base de dados diretamente como se fosse Clipper, Delphi ou VB. Dava tiro no pé quem fazia isto (não acredito que alguém ainda o faça impunemente).

Quem como eu, já trabalhou com sistema de controle de estoque em aplicações isoladas, sabe como é fácil controlar estoque de filiais com aplicações Java que usam protocolo HTTP como meio de integração.

É como o mochuara escreveu.

[]s
Luca

mochuara:

Então só porque vc não tem new Thread() no seu código não esta usando threads? :shock:

O que eu quis dizer com Swing usar inerentemente threads é que, mesmo que voce não crie threads no seu código, vc precisa ser bom em threads para aproveitar o maximo do potencial do framework, ou simplesmente não fazer merda.

Discordo. Não precisa ser bom em Threads pra usar Swing. Precisa ser bom em Java e Swing pra usar Swing.

Tem certeza que você não está confundindo Threads com eventos ?

Bird89du:

Fora software embarcado e software em tempo real, porque sistema desktop?

Minha opinião: A tendência é web então não é o java desktop que não tem força mas sim trabalhar com aplicativos que rodam direto na máquina.

vlw

Discordo.

Eu não falei que o problema era o Swing. O problema é a inicialização mesmo.

Tem certeza?

ceklock:

Uso Swing há muito tempo, e com exceção do SwingUtilities.invokeLater() e algumas poucas animações feitas com o uso de threads, eu praticamente não uso threads no código. Prefiro usar apenas quando há real necessidade, pois isso faz o código ficar mais difícil de manter.

Das duas uma ou as pessoas não sabem o que é uma thread, ou não sabem como funciona o swing.
Porque raios precisaria chamar invokeLater se não estivesse num ambiente multi-thread ?
É por causa que está num ambiente muit-thread que precisa sincronizar as chamadas ao swing usando invokeLater.

por outro lado, quando falei que a culpa é do programador era a isto que me referia. Se a pessoa não usa threads para realizar as tarefas do software ( ou seja, sempre que alguem aperta um botão) o sistema vai ser lento. SwingWorker é o jeito fácil de fazer isso e esconde todo o mecanismo de threads, mas isso não significa que não se está usando threads.

Dizer que Swing é inerentemente multithread é tão verdadeiro que é quase uma tautologia.

Quem acha que Swing é multi-thread está muito enganado.

Recomendo que vocês leiam esse artigo:

Multithreaded toolkits: A failed dream?
http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html

The Event Dispatch Thread
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/dispatch.html

Swing’s single-thread rule says that Swing components can only be accessed by a single thread. This rule applies to both gets and sets, and the single thread is known as the event-dispatch thread.

The single-thread rule is a good match for UI components because they tend to be used in a single-threaded way anyway, with most actions being initiated by the user. Furthermore, building thread safe components is difficult and tedious: it’s a good thing not to be doing if it can be avoided. But for all its benefits, the single-thread rule has far-reaching implications.

Swing components will generally not comply with the single-thread rule unless all their events are sent and received on the event-dispatch thread. For example, property-change events should be sent on the event-dispatch thread, and model-change events should be received on the event-dispatch thread.

For model-based components such as JTable and JTree, the single-thread rule implies that the model itself can only be accessed by the event-dispatch thread. For this reason, the model’s methods must execute quickly and should never block, or the entire user interface will be unresponsive.

fonte: http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html

Swing components are not inherently thread safe, and as a general rule, after Swing components have been made visible on the screen, you can only safely modify their data from the event thread. If you modify Swing component data from any thread other than the event dispatching thread, you must take precautions to ensure data integrity. An exception to this rule is the setText method on a JTextComponent or any of its subclasses, or any Swing component method whose documentation explicitly states it is thread safe.

Sometimes, you cannot avoid modifying Swing component data from outside the event dispatching thread after it has been made visible. An example is spawning a thread to handle a long operation such as reading or writing a large file over the net. The advantage to spawning a new thread is that the user interface is made available to the user for other operations during the long file operation. The spawned thread is a new thread, and therefore, not on the event dispatching thread even if it is spawned by an event dispatching thread method.

fonte: http://java.sun.com/developer/technicalArticles/Threads/swing/

Isso só diz que o Swing não é thread-safe. Mas o Sergio está certo. Justamente por ele não ser thread-safe, mas as aplicações serem multi-thread, você deve usar os métodos invokeLater e invokeAndWait.

O que esses métodos fazem é enfileirar uma requisição ao Swing numa fila de mensagens. O enfileiramento dessa requisição é thread-safe, bem como a leitura dessa fila (feita pelo Swing). Dessa forma, a thread do swing pode rodar isolada das demais threads, recebendo entradas unicamente através dessa fila.

O que você não pode fazer é com que uma thread, diferente da própria thread do swing, chame um método do swing diretamente. Como os métodos dos componentes não são thread-safe, isso poderia gerar um problema grave de concorrência e um comportamento totalmente diferente do esperado.

ViniGodoy:

Isso só diz que o Swing não é thread-safe. Mas o Sergio está certo. Justamente por ele não ser thread-safe, mas as aplicações serem multi-thread, você deve usar os métodos invokeLater e invokeAndWait.

O que esses métodos fazem é enfileirar uma requisição ao Swing numa fila de mensagens. O enfileiramento dessa requisição é thread-safe, bem como a leitura dessa fila (feita pelo Swing). Dessa forma, a thread do swing pode rodar isolada das demais threads, recebendo entradas unicamente através dessa fila.

O que você não pode fazer é com que uma thread, diferente da própria thread do swing, chame um método do swing diretamente. Como os métodos dos componentes não são thread-safe, isso poderia gerar um problema grave de concorrência e um comportamento totalmente diferente do esperado.

Sim, as aplicações é que podem ser multi-thread. O Swing não é.

Li isso no blog do Sérgio Taborda.

Li também um monte de siglas e jargões e umas teorias que não entendi. Qualidade de software, assim como qualidade de vida, é simplificar as coisas ao invés de complicar.

Ao fazer um código, ou escrever um texto, deve-se evitar escrever algo que só você entende. Se você quiser minimizar os riscos você precisa saber transmitir a sua idéia e fazer com que os outros entendam o que você fez.

E abaixo está a opinião dos criadores da interface SubArtic, sobre Threads:

Authors of the SubArctic Java Toolkit:

It is our basic belief that extreme caution is warranted when designing and building multi-threaded applications, particularly those which have a GUI component. Use of threads can be very deceptive. In many cases they appear to greatly simplify programming by allowing design in terms of simple autonomous entities focused on a single task. In fact in some cases they do simplify design and coding. However, in almost all cases they also make debugging, testing, and maintenance vastly more difficult and sometimes impossible. Neither the training, experience, or actual practices of most programmers, nor the tools we have to help us, are designed to cope with the non-determinism. For example, thorough testing (which is always difficult) becomes nearly impossible when bugs are timing dependent. This is particularly true in Java where one program can run on many different types of machines and OS platforms, and where each program must work under both preemptive or non-preemptive scheduling.

As a result of these inherent difficulties, we urge you to think twice about using threads in cases where they are not absolutely necessary. However, in some cases threads are necessary (or are imposed by other software packages) and so subArctic provides a thread-safe access mechanism. This section describes this mechanism and how to use it to safely manipulate the interactor tree from an independent thread.

http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html

Até porque o Swing não é uma aplicação, é uma API.

O que é ou não multi-thread é a aplicação. As aplicações Swing terão no mínimo a thread do Swing rodando. Que é uma thread. E geralmente, uma outra thread processando lógica de negócio.

Não confunda o swing não ser “thread-safe” com não ser “multi-thread”. Thread-safety é a capacidade de uma API de manter o estado válido mesmo quando multiplas threads chamam seus métodos, de qualquer jeito. Isso o swing não é capaz.

Entretanto, o swing pode interoperar com várias threads, desde que essas respeitem sua fila de mensagens. E, nesse caso, ele roda em aplicações multi-thread. Ficou claro a diferença?

ceklock:

es é que podem ser multi-thread. O Swing não é.

Qual seu ponto então se vc usa swing pra criar aplicações?

Achei que vc estava preocupado em criar programas comerciais, e não argumentar sobre definições que não fazem sentido nenhum. Ninguem aqui duvida que tanto o swing, como servidores web são sistemas multi-threads. A questão é qual arquitetura consegue abstrair melhor o conceito de threads para o usuário (programador).

Na web, o código do programador executa em um modelo de requisição/resposta onde uma thread é associada por requisição, e é sempre a mesma thread usada até a resposta ser enviada de volta para o cliente. Nesse modelo é fácil abstrair do programador a complexidade de uma arquitetura multi-thread já que todo o código da sua aplicação executa na mesma thread (pra cada cliente). No modelo web programadores de aplicações não precisam saber o que é thread!

Isso não é possivel com swing, pelo menos para criar aplicações relevantes vc precisa ter noção das diferentes threads que recebem eventos do usuário, atualizam/notificam componentes da tela, obtem e exibe dados, etc. Mesmo que ela tenha outro nome, seja Timer, EDT, invokeLater, e o escambau.

mochuara:

ceklock:

es é que podem ser multi-thread. O Swing não é.

Qual seu ponto então se vc usa swing pra criar aplicações?

Achei que vc estava preocupado em criar programas comerciais, e não argumentar sobre definições que não fazem sentido nenhum. Ninguem aqui duvida que tanto o swing, como servidores web são sistemas multi-threads. A questão é qual arquitetura consegue abstrair melhor o conceito de threads para o usuário (programador).

Na web, o código do programador executa em um modelo de requisição/resposta onde uma thread é associada por requisição, e é sempre a mesma thread usada até a resposta ser enviada de volta para o cliente. Nesse modelo é fácil abstrair do programador a complexidade de uma arquitetura multi-thread já que todo o código da sua aplicação executa na mesma thread (pra cada cliente). No modelo web programadores de aplicações não precisam saber o que é thread!

Isso não é possivel com swing, pelo menos para criar aplicações relevantes vc precisa ter noção das diferentes threads que recebem eventos do usuário, atualizam/notificam componentes da tela, obtem e exibe dados, etc. Mesmo que ela tenha outro nome, seja Timer, EDT, invokeLater, e o escambau.

Editando: Não sei, você e o Sérgio Taborda que começaram a falar sobre Threads.

Minha participação nesse tópico encerra por aqui, pois saiu completamente do assunto original.

Olá

ceklock:

C++ is a general purpose programming language designed to make programming more enjoyable for the serious programmer. (Stroustrup 1987)

Clojure is based on the idea that programming can and should be much less complex. (Rich Hickey 2010)

Uma dúvida:

Quando você programa em C++ ou em Clojure para um ambientes de janelas como no Windows ou no X do Linux, você precisa se preocupar com threads? Ou o C++ ou o Clojure tratam tudo automaticamente para você?

Caso tenha respondido que o C++ ou o Clojure tratam threads automaticamente, como faz para colocar na tela uma figurinha mostrando a execução de alguma tarefa em background e no fim alertar que acabou?

[]s
Luca

Luca: não sou eu que uso isso na assinatura. Favor corrigir.

Fui.

Olá

ceklock:

Luca: não sou eu que uso isso na assinatura. Favor corrigir.

Fui.

DESCULPE!!!

Não sei como entrei nesta de pensar que era você. Mas pelo menos fica a oportunidade de dizer que quando a gente programa para Windows (ou janelas de forma genérica), coisas diferentes podem acontecer em diferentes janelas ou uma janela pode precisar executar alguma coisa em background (como acessar um servidor, por exemplo) e colocar uma figurinha pacificadora para que ninguém pense que travou. Com Java isto é bem simples porque usar Threads em Java é coisa trivial. Já em C/C++ não é que seja difícil mas dá um pouquinho mais de trabalho.

Como este tópico é sobre Swing, acredito que quando alguém aqui fala em aplicação web quer dizer que a camada de apresentação é Swing. E além das threads que ocorrem no servidor controladas pelo servidor de aplicações, se pode usar threads nas janelas como nos exemplos que citei. Nada difícil de aprender. Antigamente antes do Java 1.4 quando o Java ainda não tinha SwingWorkers, etc. a gente usava uma API de terceiros chamada foxtrot com o mesmo intuito. Ver http://foxtrot.sourceforge.net/

[]s
Luca

Luca:

Olá

ceklock:

Luca: não sou eu que uso isso na assinatura. Favor corrigir.

Fui.

DESCULPE!!!

Não sei como entrei nesta de pensar que era você. Mas pelo menos fica a oportunidade de dizer que quando a gente programa para Windows (ou janelas de forma genérica), coisas diferentes podem acontecer em diferentes janelas ou uma janela pode precisar executar alguma coisa em background (como acessar um servidor, por exemplo) e colocar uma figurinha pacificadora para que ninguém pense que travou. Com Java isto é bem simples porque usar Threads em Java é coisa trivial. Já em C/C++ não é que seja difícil mas dá um pouquinho mais de trabalho.

[]s
Luca

É simples sim. Para executar processos longos vc vai usar o SwingWorker (ou pode usar Clojure tb).

http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html

Para animar a tal figurinha vc faz via EDT.

Olá

Como o Banco Postal foi feito usando Java 1.3, usamos o Foxtrot com este intuito. Mas mesmo hoje em dia ainda se pode optar pelo uso do Foxtrot caso prefira usar um modelo síncrono ao invés de assíncrono.

[]s
Luca

Entenda que Swing é um framework para criar aplicações. O que é single-thread é apenas uma parte da arquitetura, aquela que corresponde a GUI.

Luca:

Olá

Como o Banco Postal foi feito usando Java 1.3, usamos o Foxtrot com este intuito. Mas mesmo hoje em dia ainda se pode optar pelo uso do Foxtrot caso prefira usar um modelo síncrono ao invés de assíncrono.

[]s
Luca

Luca,

Não conheco esse tal de Foxtrot, mas se não tiver como usar java 6 ou Clojure, não esqueca que vc pode ainda usar POT (Plain Old Threads).

Olá

O Foxtrot funciona com Java 6 só que seu modelo é síncrono. No java 1.3 é que não havia outra alternativa.

[]s
Luca

Aew galera… essa briga por um lado é construtiva, mais por outro deixa levar o que java tem de melhor… DESKTOP e WEB.

Ai os outros brigam por WEB e perdemos aqueles que também poderiam programar para DESKTOP. e vice-versa

mais o foco não é esse, o foco é saber a logica da programação, programar orientado a objetos e não a POG, saber ensinar, saber criar métodos genéricos para uso de todo mundo, não replicar códigos, elaborar soluções inovadoras e estar ligado nas atualizações de JAVA em si, e não nas tendências, por que isso é muito relativo, uma hora é WEB a outra é DESKTOP. Não contem com isso. Eu programo tanto para WEB(que fico ligado nas ferramentas novas: RichFaces, Hibernate, PrimeFaces, JQuerry, New Jboos, JFreeMark) quanto para DESKTOP(Com o Java 7, com o novo ‘CATCH’, os novos meios de criar uma variável Int, Criando o seu próprio modelo de JTable, SwingUtilies com GRAPHICS Integrador, Gráficos atualizados em tempo real e tudo mais, e atualizações quase chegando para o JAVA 8), o mercado ta muuuito competitivo tanto para WEB quanto para DESKTOP. Ou voces acham que aquelas aplicações de B.I. - Bussines Inteligence qua ilustra gráficos vetoriais, com dados de produtos, ou voces acham que os gráficos para auxílio na tomada de decisão na parte governamental de uma empresa é feito via WEB? . GALERA, Hackeres são inteligentes, é muito mais simples o abestado ir la e estudar para invadir sistemas via WEB do que invadir aqueles softwares robustos feitos em java, que é 90% mais difícil.

#Pensem nisso!