Home  ·  Search
JavaMan
 
 A Tecnologia Java


JavaMan
SouJava
java.sun.com



Links


Java
-
Produtos
-
JUGs no Brasil
-
Projetos
-
Artigos

Sobre o JavaMan
-
Curriculo
-
JavaBaby
-
o Site
                   


Índice para o Restaurante

A Tecnologia Java
18 de julho de 2002



Convidado: Bruno Souza, o JavaMan brasileiro
Moderador: Handerson Gomes (handerson)

Esse é um fórum moderado.

handerson: Pessoal, vamos dar inicio ao nosso primeiro jantar no Restaurante no Fim do Universo. Nosso convidado hoje é o Bruno Souza, conhecido como o JavaMan brasileiro e o assunto de hoje e a Tecnologia Java.

handerson: Perguntem a vontade.

javaman: A intencao aqui é discutir a tecnologia Java em geral, portanto, fiquem a vontade para fazer questões diversas.

mauricio: para o pessoal (incluindo o Bruno), já que ninguém começa.... eu coloco fogo: o que vocês acham da disputa J2EE x .NET?

javaman: Em relação a J2EE vs .Net. A disputa vai ser boa. A Microsoft tinha um problema de não ter nenhuma tecnologia a altura do J2EE, que estava dominando de lavada o mercado. Agora, com o .Net, a Microsoft conseguiu dar uma alternativa para aqueles clientes deles que estavam migrando para Java por falta de opção. Mas, .Net ainda é uma tecnologia totalmente imatura, tem muito chão para atingir o J2EE. E isso tem a vantagem de que nos, do nosso lado, precisamos evoluir, para não sermos alcançados.

Claudio4J: Mas o .Net não possui tecnologia de persistência de objetos, que é um dos carros chefes de J2EE

javaman: Certo, .Net ainda não tem algumas das características que J2EE possui.

mauricio: isso que eu ia ressaltar Claudio, a .Net ainda não tem o fôlego de Java (de uma maneira geral) sem contar que muitos aspectos da OO não foram implementados

javaman: Por outro lado, as ferramentas de desenvolvimento (que são tudo que existe por enquanto) se mostraram bem poderosas, por isso, os fornecedores J2EE precisam evoluir.

Claudio4J: JavaMan: como você enxerga o mercado Java (tecnologia Java) daqui a 2 anos

javaman: Quanto ao mercado Java daqui a 2 anos, tem algumas coisas que podemos começar a pensar. Primeiro, as arquiteturas distribuídas estão evoluindo. J2EE, .Net, WebServices são as tecnologias distribuídas do passado, e não do futuro. São apenas a padronização do que todos nos fazíamos. Daqui a 2 anos, essas tecnologias estarão sendo utilizadas por todas as empresas. E quem esta na vanguarda tecnológica, já estará experimentando com as novas formas de distribuição. Pensar em P2P, grid computing, Jini, essas sim são as tecnologias que só vão começar a crescer daqui a algum tempo.

mauricio: Bruno, poderíamos citar a evolução J2ME para dispositivos de bolso também estou certo?

javaman: Sim, o uso de J2ME, e a utilização de dispositivos diversos, fará uma diferença grande nesse mundo distribuído, já que com milhões de devices, a distribuição de aplicações fica bem mais interessante (e complicada). E o que falamos a muito tempo (milhões de devices) pode parecer mais uma coisa do futuro, mas já é uma realidade hoje, em diversas áreas. Daqui a alguns anos, isso será o normal.

lmike: e JXTA? Também será mais utilizado?

javaman: JXTA é uma implementação de infraestrutura P2P, e com certeza, será uma tecnologia que temos que ficar de olho. Agora, usar P2P é algo que ainda não sabemos bem o que vai nos trazer, é uma tecnologia que esta ainda no "futuro". E as aplicações começarão a aparecer daqui a algum tempo.

mauricio: quais são os aspectos da grid computing?

javaman: Grid computing é a tecnologia voltada para realizar processamento pesado e distribuído. Gerenciar grande (centenas e milhares) de recursos distribuídos, de forma a fornecer uma infraestrutura única para processamento. É a idéia de você ter um "computador na rede". Ou, a visão da Sun, "a rede é o computado"... :-)

RGB: Bruno, você tem informação de quando teremos JavaServer Faces madura ?

javaman: JavaServer Faces estará disponível esse ano, agora, madura, é uma outra questão. JSF é uma tecnologia de ferramentas de desenvolvimento, e vai depender dos fornecedores de ferramentas disponibilizarem ferramentas de bom nível. JSF pode ajudar a popularizar o J2EE, devido a facilidade de desenvolvimento, e cabe aos fornecedores correr com isso, para inclusive fazer frente ao .Net.

Claudio4J: Existe uma thread de discussão no TheServerSide sobre a HP descontinuar WebServices (NetAction) e o HP-AS (antigo Bluestone), e a moral da discussão era que a plataforma Java estava muito apoiada em cima dos fornecedores J2EE. Como você vê isso (no Brasil) ?

javaman: Como assim a plataforma Java esta apoiada em cima dos fornecedores J2EE?

Claudio4J: Como sendo os grandes patrocinadores da plataforma Java (IBM, Sun, BEA, etc). Pois as tecnologias do lado servidor são mais vistas através dos fornecedores J2EE.

javaman: Bem, na verdade, essas são grandes empresas de middleware. Isso era esperado que acontecesse uma consolidação de servidores, com aquisições e descontinuamento. O mercado não vai absorver dezenas de produtos. Do mesmo jeito que houve uma consolidação de bancos de dados, servidores web, esta acontecendo com appservers. Isso todo mundo esperava. E é claro que os grandes vão ficar maiores. Agora, com a API aberta, produtos como o JBoss podem aparecer, e virar o jogo (como foi o Apache), o que é interessante para o mercado.

Claudio4J: Mas como empresas como HP puderam levar tanto prejuízo ? (compra do BlueStone, NetAction, WebServices)

javaman: Mal gerenciamento? :-) Não sei, mas vão se sobressair as empresas que tenham cultura de middleware. A HP em particular, demorou muito tempo apostando no produto proprietário deles, antes de partir para a compra de um produto J2EE. Além disso, as empresas que você citou: IBM, BEA são grandes empresas de middleware. A Sun é a "novata" no mercado, e não esta se saindo bem também.

mauricio: e o foco de programação para internet? o chamado e-commerce usando Java, tende a crescer?

javaman: Sim, como sempre. Java é hoje a principal tecnologia para desenvolvimento de sites de e-commerce. A menos que Java falhe por um motivo ou outro, isso deve continuar a crescer. Por outro lado, o e-commerce esta mudando de cara, e deve diminuir o numero de sites, e passar a uma interação maior entre empresas (ai é que entram os WebServices). Isso já esta trazendo uma nova forma de desenvolver aplicações, que é muito interessante.

mauricio: você acha que existirá um esgotamento ou não???

javaman: Esgotamento de e-commerce é difícil. Mesmo em negócios normais, é difícil "esgotar" um mercado. Áreas especificas, com certeza, mas o e-commerce é grande.

Claudio4J: E as aplicações de desktop ? normalmente vemos muitas aplicações servidoras, por que você acha que não é mostrada (ou não existem) tantas aplicações Desktop (caixa, contas a pagar, folha de pagamento, CRM, etc.) ?

javaman: Aplicações de desktop diminuíram porque a web passou a ser tão falada. É uma pena, mas as pessoas estão achando que HTML resolve tudo, o que não é verdade. Aplicações de desktop são muito mais interativas do que as HTML, mas as empresas "esqueceram" disso. Hoje, com o Java WebStart por exemplo, você tem o melhor dos mundos: distribuição semelhante ao HTML, e interação de desktop. Nessa hora que começamos a ver a distribuição de aplicações voltar a ser importante. Aplicações P2P serão assim, o que deve fortalecer esse tipo de aplicação.

Facunte: O que o nosso amigo Claudio4J questionou é bastante interessante, no meu ponto de vista, nos desenvolvedores, professores, escritores, devemos incentivar mais este tipo de desenvolvimento.

mauricio: a questão de plataforma na pergunta do Claudio pode ser levada em conta também ?

javaman: Sim, é importante que as pessoas, desenvolvedores e gerentes entendam que HTML é o terminal burro colorido. Quando saímos do terminal burro, foi porque precisávamos de maior interação, e é isso que precisamos hoje. Não se compara uma aplicação de desktop (em matéria de interface, sofisticação e facilidade de uso) com uma HTML. A HTML é muito pobre e limitada (sem contar, difícil de manter). E a questão da plataforma é fundamental. Por isso Java é multi-plataforma. Aconselho a todos olharem o JavaWebStart, vale a , vejam os exemplos e ficarão assustados (no bom sentido). http://java.sun.com/products/javawebstart

mauricio: refazendo a minha pergunta: eu quis dizer em termos de desempenho, pois acho que antes não tínhamos app desktop por causa do desempenho de maquina (jre) principalmente em termos de interface... hoje esta diferente?

Claudio4J: O interessante neste tipo de desenvolvimento (aplicações desktop) hoje o Java é bem mais maduro, em que podemos desenvolver aplicações de ponta a ponta.

javaman: Ou seja: Java tem performance para isso?

Facunte: Tenho percebido que a cada nova versão do JDK, temos melhorias no quesito performance. Acredito que a maior barreira para o desenvolvimento de aplicações Desktop, ainda é a suposta "lentidão", o que vocês acham? Apesar é claro do HotSpot

javaman: É claro que Java melhorou muito, e a verdade é que temos aplicações Java de interface que são tão rápidas quanto outras não Java. Mas Java ainda tem alguns problemas, principalmente uso de recursos. Você já viu Java no MacOS X? É muito rápido. Porque a Apple mudou a JVM, e resolveu a questão dos recursos. Isso estará no JDK 1.5

mauricio: depende do estilo de interface a ser usada eu acho!

javaman: Mas isso não significa que não da pra fazer aplicações altamente interativas, com Java, muito pelo contrario. Outra coisa que precisamos entender é que Java é PÉSSIMO nos browsers. Não é lento, é lentisssssssssssimo.

mauricio: isso é verdade.... concordo contigo...

javaman: Por isso, é importante que passemos a utilizar a ultimas versões, para ganhar as vantagens de performance da plataforma. Mais uma vez, o JWS vem no nosso apoio aqui.

Claudio4J: Mas, eu já vi casos, em que só por que Java possui GC, faz um monte de coisas pelo desenvolvedor, e ele acaba não liberando recursos adequadamente (o que compromete o sistema)

javaman: Certo. Java não impede que o desenvolvedor faca uma aplicação ruim.

mauricio: ai você ressaltou uma coisa perfeita e inclusive eu notei principalmente versão 1.4 j2sdk........ eu achei mais rápido

javaman: E é isso que precisamos combater, precisamos de aplicações que sejam bem feitas. Sim. Java vem melhorando de performance e muito.

handerson: Bruno, quando vamos ver produtos utilizando JINI?

javaman: Bem, já começaram a aparecer. o JRun usa Jini para fazer cluster e load balance.

handerson: Produtos domésticos, pois o JRun já utiliza JINI em seu cluster.

javaman: Uma coisa que Jini foi mal entendida (na verdade, mal apresentada pela Sun) é que disseram que Jini era para aparelhos, o que é uma grande balela. Jini é uma arquitetura distribuída, muito interessante, e em vários casos, mais poderosa e mais simples que J2EE, mas ninguém se tocou disso...

fgm: a tecnologia j2me é um futuro promissor???

Claudio4J: E o mercado de j2me no Brasil, por que não vemos aplicações nos celulares ?

javaman: J2ME tem um grande futuro, mas somente esse ano que estamos vendo as primeiras operações comerciais a nível mundial. No Brasil, as operadoras ainda estão muito devagar com isso. Mas no mundo todo também esta assim. Porque é uma nova forma de vender serviços, e muitos não sabem o que isso significa, nem como ganhar dinheiro. Além do que, o fracasso total do WAP (que como tecnologia era péssimo), assustou os usuários e os fornecedores. As operadoras estão mais cuidadosas agora....

fgm: teria algum problema de exemplo onde usaria Jini ao invés de J2EE??

javaman: Qualquer problema que você precisa fazer balanceamento de carga (por exemplo), que é uma das "grandes vantagens" do J2EE, Jini é mais simples, e mais natural. Sempre que você tem varias maquinas envolvidas (ambiente realmente distribuído) Jini será mais natural do que J2EE, mas as pessoas não entendem isso.

(depois do restart do servidor que crashou devido a uma besteira do administrador...) 

javaman: Bem, aparentemente, o sistema crashou, e perdemos todos os usuarios...

javaman: Pessoal, o sistema crashou, estamos dando uns minutinhos para o pessoal voltar...

Facunte: eu comentava sobre a palestra do dia 25.07, onde o tema são os servidores de aplicação, o mercado é bastante disputado, ate mais do que o mercado de bancos de dados. Estou certo disso?

javaman: O mercado esta disputado sim, mas ainda tem muita gente sem qualificação, o que dificulta o trabalho do pessoal qualificado. Por isso é importante elevar o nível do profissional Java brasileiro. E esse é um trabalho de todos nos. :-)

fgm: Bruno, e o brasil Java one, pode dar uma previa do que vai rolar no dia?

javaman: Você esta falando do evento Abaporu. Iremos apresentar as melhores palestras que rolaram no JavaOne. Isso não é um "JavaOne Brasil", mas sim, trazer a informação do JavaOne 2002 para o Brasil (diferença sutil, mas importante...)

handerson: Facunte, você tinha uma pergunta sobre o JDK 1.5, você pode enviar sua pergunta?

javaman: (para quem chegou agora, o sistema crashou, então, estamos entendendo o papo mais um pouco...)

Facunte: Quais as mudanças mais significativas no JDK 1.5? Será q estou um pouco apressado em relação a versão?

javaman: Bem, tinha uma questão sobre o JDK da Apple. A Apple implementou (entre outras melhorias) o equivalente a "shared libraries", o que evita por exemplo que você utilize 16-20Mb de memória por cada VM iniciada na maquina. O JDK 1.5 trará como um dos carros chefes a questão de "shared libraries" para Java. Isso será um grande ganho para a utilização eficiente de recursos. Mas a especificação do 1.5 ainda esta no Java Community Process, portanto, muita coisa pode acontecer...

Facunte: Poxa isso me parece muito interessante "shared libraries". Realmente é um fortíssimo avanço

Claudio4J: O JDK 1.5 é conhecido como Tiger

javaman: É algo comum nos sistemas operacionais, e esta faltando em Java...

Claudio4J: Algo que pode melhorar muito a plataforma Java em ambientes SMP, é que ainda não foi implementado (nem Sun, IBM) o conceito de stack floating points, que faria com que JVM em sistemas SMP tenham aumento de performance de até 40%

fgm: voltando ao assunto do j2me, é uma boa opção para soluções em palms, handheld? 

javaman: Sim, é uma boa opção, mas o J2ME ainda precisa evoluir para atingir os features de desenvolvimento nativo dessas plataformas. A grande vantagem do J2ME é a portabilidade, que é mais importante no mundo de celulares do que no mundo de PDAs.

Facunte: Bruno, quem pode ajudar a melhorar o Java? Por exemplo: o JBuilder possui diversos "componentes" desenvolvidos pela Borland que facilitam o acesso a banco de dados, JSP, J2ME, etc, etc, etc. Não seria a hora de desenvolvedores enviarem suas "classes" para a analise da SUN, onde a mesma poderia implementá-las

javaman: Isso já é feito! Não se esqueça que o JCP é o processo onde isso é feito. A maioria das melhorias de Java vieram dessas empresas. Por exemplo, você citou uma lista de componentes. O JavaServer Faces nada mais é do que a padronização de alguns deles. Portanto, a grande forca da tecnologia Java, vem do apoio das empresas e da comunidade, via o JCP.

Facunte: Mas então a SUN esta tornando o processo lento, ou a falta de desenvolvedores qualificados JAVA no mercado acarretam nesta demora.

javaman: Não. O JCP é um dos processos de padronização mais rápidos do mercado. Você não precisa que tudo seja padronizado, sempre é importante que coisas evoluam fora do processo!

fgm: poderia indicar algum bom livro sobre arquitetura j2ee?

javaman: Eu sugiro o Mastering Enterprise JavaBeans, que esta gratuito no site theserverside.com, o livro é muito bom, e de graça :-)

javaman: Pessoal, nosso tempo mais que esgotou. Espero que esse primeiro chat tenha sido valido.

Claudio4J: ok, foi muito bom, abraços, até o próximo jantar

fgm: obrigado

javaman: O chat continuara ativo, para quem quiser continuar aqui.

handerson: Ultimo moderador (eu) saindo. O chat agora está liberado.

Como esse foi o primeiro Jantar, guardamos também a conversa "pós-jantar". Veja as melhores partes!




Home  ·  Search

[ Envie seus comentarios para o JavaMan ]