Apesar da plataforma Java não deixar nenhuma dúvida do seu amadurecimento, nos dá ainda mais segurança em ver a Sun colocando em prática todo o discurso de encarar .NET através da declaração do Mr. Green. Não sei como os demais vêem tal notícia, mas sei que o primeiro passo precisava ser dado. Alguém pode até dizer que as primeiras atitudes já tinham sido tomadas, mas no sentido do desenvolvedor java considero essa iniciativa da Sun singular até o momento.
Mas vale lembrar que a Sun ainda está apenas pensando em se aliar. Claro, seria muito bom para a comunidade Java, muito bom para os usuários do Eclipse, muito bom para a IBM e muito bom para a Sun. Porém, há questões que precisam ser resolvidas antes da Sun fazer parte do clubinho Eclipse e, a maior delas (na minha opinião) nem é o fato de a IBM ser o project leader do Eclipse, mas sim a :agrue: briguinha por padrões (Swing vs. SWT).
Estava esperando alguém tocar no ponto nevrálgico da questão: Swing X SWT. Agora não sei quem vai ceder (se é que alguém vai ceder)… mas acredito que o próprio interesse da Sun pela plataforma Eclipse já é uma demonstração de que ela terá que abrir mão de ser tão xiita quando o assunto é padronização, se não qual seria outro interesse?
Acho que a briga Swing vs SWT vai acabar sendo resolvida logo logo… assim que a SWT estabilizar mais, a IBM vai tentar colocar ela em uma JSR… entrando o “suporte” da Sun, talvez tenhamos um javax.swt em breve 
Vou fazer algumas colocações, as quais não tenho certeza, e espero alguém esclarece-las para mim:
-
SWT não é multiplataforma, ou seja, precisa de uma API para cada SO, certo??
-
SWING é multiplataforma, já que é interpretado pela JVM, certo?
Então onde fica o slogam: “Write once, run anywhere”?? Já que tenho que distribuir várias versões de SWT junto com kinha aplicação…???
Valeu galera, espero ser corrigido se cometi algum equivoco…
A codificação é a mesma para qualquer plataforma. Se não me engano, o que muda é só o interpretador. Por isso acho que é possível embutir o interpretador SWT na JVM
não é exatamente o interpretador,
o SWT é uma biblioteca Java como qualquer outra, e em sua maior parte, tão multi plataforma quanto qualquer outra
a unica coisa que é diferente para cada plataforma, são as DLLs dos componentes JNI utilizados pelo SWT
isto não é impedimento nenhum para adiçãi ou não do SWT na JRE pois o proprio AWT é todo, ou quase todo feito com JNI, a unica diferença é que no caso do AWT as bibliotecas nativas vem junto com a JRE e no caso do SWT vem num download separado.
no fim das contas eles vao deixar o swing e o SWT… num faz mal ter variedade… ((:
acho q a briguinha maior vair ser pra ser quem é o project leader, a ibm num vai abrir mão nunca e a Sun quer mandar tb né, eles num vao abaixar a cabeça nunca…
e o Forte?? q a sun vai fazer?? ela disse q num abre mão dele, e a ibm tb num abre mao da ferramenta dela…
dureza…
Acho que vai continuar na mesma, assim como a Oracle continua com o JDeveloper, a Borland com o JBuilder… A Sun vai apenas patrocinar o projeto, não vai substituir suas ferramentas pelo Eclipse.
swing + awt + swt
Cara, so para mim que parece ser completamente bizarro voce ter 1 software que vem com 3 APIs para fazer exatamente a mesma coisa??
[quote=“louds”]swing + awt + swt
Cara, so para mim que parece ser completamente bizarro voce ter 1 software que vem com 3 APIs para fazer exatamente a mesma coisa??[/quote]
Acredito que o AWT ainda esta ai porque o Swing nao faz tudo sozinho - podemos enxergar AWT como base para o Swing.
Agora, incluir o SWT tambem? Pra mim ficaria estranho tambem…
Ueh, vamos colocar o GTK tambem nessa historia! E tudo quanto eh toolkit que tenha bindings pra Java! 
Marcio Kuchma
Este é apenas um dos motivos pelas quais eu acho que não rola um javax.swt. Além disso, SWT chuta para longe o WORA, principalmente quando você faz acesso a (por exemplo) OLEs em SWT-win32.
Para que SWT seja embutida na JPI vai ser preciso muita conversa entra Sun e IBM. Aliás, seria muito bom que a Sun ouvisse um pouco o que a IBM tem a dizer.
Olá Amigos.
Pessoalmente eu acho que a JavaSoft(SUN) não irá aderir ao SWT como um padrão e distribuí-lo na JRE, justamente pelos Peers Nativos existentes em cada plataforma e ainda levando em conta a quantidade de versões de Widgets atuais. Um dos quesitos é ser 100% Java.
O AWT e a maior gambiarra dentro dos SO’s. E ele so existe no Java, pois em 1995 a Sun não tinha escolha para implementar o suporte a aplicações visuais. E foi necessario gera modulos em C++ especificos para cada plataforma. Por isso foi descontinuado e substituido pelo SWING, 100% Java e extremamente complexo, lento e pesado.
Entretanto, isso não impede que façamos sistemas usando o SWT que necessitem de alta performance no cliente com algumas restrições de portabilidade…
O que não podemos esquecer, é o foco do Java: Enterprise Applications. Ou seja, ambiente de larga escala, server-centric, que suporte clientes HTML, WebServices e Wireless.
O foco do Java não é o lado do Client, e sim mecanismos que permitam vários tipos de clientes acessar uma aplicação distribuida.
[]'s
Alguém aí avise o Scott McNealy, pois ele deve estar errado em querer levar Java aos desktops .
Hummm … errado em querer ele não está … mas dai pra conseguir tem chão pacas :shock:
O Swing não é o caminho a meu ver … to mais pro SWT …
desde a primeira vez que eu vi o Java rodando como desktop com JFrame, eu achei bem lento (em um PIII 450mhz com 128 ram), comparado a outras linguagens como Delphi e VB. Claro que Java é multiplataforma, roda em cima de uma VM, tem garbage collection que deixa mais lento a aplicação e etc… mas com Swing eu nunca acreditei.
Depois que vi o Eclipse e SWT (ainda nao tive oportunidade de criar nada em SWT, apenas vi o Eclipse), o desempenho ao meu ver em computadores mais lentos é bem melhor, ae sim tavles o Java comece uma caminhada legal para Desktop.
Seria muito bom Java dominar Desktop, Web e periféricos com pouca memória 
[quote=“ozielneto”]O que não podemos esquecer, é o foco do Java: Enterprise Applications. Ou seja, ambiente de larga escala, server-centric, que suporte clientes HTML, WebServices e Wireless.
O foco do Java não é o lado do Client, e sim mecanismos que permitam vários tipos de clientes acessar uma aplicação distribuida.[/quote]
Eita, o foco da tecnologia Java mudou, e eu não tava sabendo! Até onde essa minha vã e mal-informada consciência que eu tenho me leva, Java era pra estar “everywhere”…
Java é bom para Enterprise Applications, seja lá o que os marketeiros das grandes empresas querem enfiar na nossa cabeça ao definir o que é uma “Enterprise”. Enterprise pra mim ainda continua sendo uma nave bem grande que o pessoal do Star Trek usava - pra mim, existem aplicações server-side, e aplicações client-side, coladas por algum tier no meio do caminho. E Java joga bem em todas essas posições - de smartcards a mainframes, de celulares a desktops, de máquinas de sorvete a ferramentas de gerenciamento de redes, de… bom, vcs entenderam a idéia.
Se a Sun quiser dar uma de dona da bola (afinal, ela tem poder de veto em qualquer JSR no Java Cartel^H^H^H^H^H^HCommunity Process), as tecnologias Java vão continuar a evoluir, mas elas poderiam evoluir BEM mais rápido se ela deixasse o resto do pessoal brincar - especialmente a IBM.
Curiosidade mórbida: eclipse serve pra esconder o sol (Sun)… alguém já tinha pensado nisso?
[quote=“cv”]
Curiosidade mórbida: eclipse serve pra esconder o sol (Sun)… alguém já tinha pensado nisso? :D[/quote]
essa piada é velha 
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2860393-2,00.html