A promessa da Sun continua agariando partidarios

ObjectWeb EasyBeans Released: Open Source EJB3 Container

Mais um container EJB 3.0 lançado no mercado, o interessante é que nem mesmo a especificação está pronta e o mercado parece já respirar EJB 3.0. Será que isso tudo é desespero ? Quem aqui já teve que desenvolver alguma coisa usando EJB 2.1 ? hehehe é uma coisa bem interessante , é a típica coisa que você olha e diz: “Meus Deus , como eles pensaram em tudo” . Mas depois de algum tempo codificando milhares de linhas de XML e fazendo referencias muitas vezes duplicadas, você chega a conclusão de que “Poderia ser mais fácil” ou pior ainda , “O framework facilmente poderia ser mais poderoso e simples”. É isto que a Sun tem tentando com o EJB 3.0 , Gavin trouxe isso para a Sun , mostrou que o seus Entity Beans são uma bomba. A única coisa que não me agrada na especificação EJB 3.0 é que os Entity Beans não vão poder mais ser cacheados de forma remota, pelo que me lembro isto é essencial para um Cluster de Application Server, afinal os entitys ficavam não num lugar especifico, mas sim distribuído por todo o Cluster, mas tudo bem , a coisa toda melhorou muito mais que piorou, as únicas pessoas que ainda não gostaram é o pessoal do Spring Framework , mas como este mundo Java é feito de padrões, eles estão um pouco de fora.

Seus dados estão realmente seguros ?

Você !!! sim você mesmo, acha que realmente esta mantendo seus dados seguros ? Você amante do PHP , acha uma solução realmente indiscutivelmente mais rápida para o desenvolvimento ? Noticias como esta “Worm Lupper "evolui" e volta a ser ameaça a servidores” nos fazem pensar se “desenvolver rapidamente” é realmente compensador , porque estou falando isso ? simples... as vezes o que vale é algo chamado “Segurança” coisa que os programadores Java estão inundados, a JVM oferece um casulo para a aplicação de forma que programas bugados ou “mal comportados” não passem da JVM , isso garante que noticias como esta do WORM para PHP (XMLRPC mais especificamente ) sejam motivo de chacota para a comunidade Java , afinal , o maximo que aconteceria no caso de algum bug na implementação XMLRPC de Java , um acesso ao ClassLoader daquela aplicação, não liberando acesso ao “usuário” do servidor , nem dando acesso a uma shell diretamente no console da aplicação. Alguns fanáticos poderiam dizer “Mas se a JVM tiver o bug” , bem , em tempos atuais é bem mais fácil encontrar um bug dentro de uma implementação de um framework/algoritimo do que dentro de uma maquina virtual testada por bilhões de pessoas.

Java estaria com os dias contados ?

Será ? As vezes tenho a impressão que o mundo respira .Net , todo mundo que você conversa só fala em VisualBasic.NET , estaria Java com os dias contados ? Estaríamos todos vivendo em uma ilusão ? Será o benedito ? HEHE

Em minha humilde opinião Java esta caminhando para um lado perigoso, o mesmo lado que a maioria das linguagens como C++ estava a algum tempo atrás. A Sun tem investido horrores em sua plataforma Java , e num ímpeto de deixar as coisas mais “fáceis” esta enchendo a linguagem Java de coisas , muitas delas sem tempo para o mercado absorver, isso desgasta o setor corporativo , afinal, temos muita VM 1.3 rodando por ae... e não podemos nos esquecer , mesmo que tenhamos alguns problemas de “compatibilidade” , um caso clássico é o Hibernate , que para compilar em versões 1.3 e 1.4 do java simplesmente abriu mão da implementação de generics em sua versão 3.0 , resultado ? quem usa no Tiger tem que ficar colocando @SupressWarnings a cada .list()

Quando você tem uma linguagem muito cheia de “nove horas” , abre-se precedentes para novas linguagens mais simples e mais elegantes ( como aconteceu com o C++ no surgimento do Java ) , isso preocupa ainda mais quando você começa a introduzir outras linguagens na plataforma , que é o caso do Groovy , que SIM tem seus méritos , mas esta contribuindo para esse “inchamento” da plataforma Java.

Como enterrar um empresa de sucesso

Parece que foi ontem, meu desespero quando a Borland anunciava o começo do fim , o lançamento do “Delphi 8 for .Net Framework”. Lembro que fiquei pasmo em ver a borland apostando todas suas fichas numa plataforma de desenvolvimento CRUA e ainda bastante incompleta. Naquela época eu não programava em Java ainda , apenas em Delphi , então a Borland era TUDO que eu tinha em minha carreira profissional, não acreditando no que ela estava fazendo fui ao show de lançamento do Delphi 8 aqui em Curitiba , e quando o palestrante perguntou “Alguém sabe para onde que a Borland vai ?” , não me contive e levantei o braço dizendo “Pro buraco !”. Bom , parecia brincadeira... mas pelo visto é para lá que ela foi...

Enquanto a Borland competia com a Microsoft criando suas próprias regras, não estava presa a nenhuma “limitação” dentro do Windows, então ela conseguia CRIAR COISAS NOVAS mesmo sem o dedo da Microsoft, já com o .Net , são as regras da Microsoft , da forma que a Microsoft manda , quantas vezes a Microsoft mandar. O Delphi 8/2005/2006 não faz nada alem do que o .Net Framework permita, não cria nenhuma telinha a mais se o .Net não permitir, tudo preso a uma plataforma que é controlada por uma empresa conhecida mundialmente por mandar “padrões” as favas, exemplo clássico disso é o “Internet Explorer” que é uma mistura de “O que não se deve fazer” adicionado com “Péssimas implementações de padrões conhecidos” , o pessoal do Tableless sabe quem do que estou falando.

Delphi 2006 é uma piada, um produto novinho... que gera assembly para .net 1.1 , que MARAVILHA HEIN ? o seu concorrente tem um produto prontinho para versão 2.0 enquanto a Borland apenas trabalha com um framework fraco e pobre de recursos , Vs.Net 2005 anuncia que códigos foram reduzidos em 70%. Agora me responda, se você fosse dono de uma “software house” você esperaria mais 8 meses para poder usar a versão do delphi nova que vai suportar .Net 2.0 ? Faria com que seus programadores escrevessem 70% mais código durante 8 meses a TOA ? é pra dar risada mesmo....

A borland não esta nova nesse mercado de fazer as coisas nas coxas, veja o caso do JBuilder, em sua versão 2005 não integrava com o JBoss 4.0 , é pra dar risada, ou tem alguém hiper conservador lá dentro , ou tem um bando de imbecis mesmo... e quem ganha mercado com isso ? Eclipse !!! O JBuilder conseguir sair de uma fatia de 36% do mercado mundial para apenas 5% em menos de 2 anos...

Isso nos leva a crer que não é apenas culpa da aposta na plataforma .Net que as coisas estão indo pro buraco , é principalmente culpa da gerencia desta porcaria de companhia. Agora eles podem sair falando para os “coitados” programadores de Delphi para .Net , que quem esta abandonando o barco agora são eles... e o ultimo que apague a luz.

JDeveloper - A salvação da lavoura ?

Estive pensando...

JDeveloper é uma das ótimas ferramentas que a oracle vem doando para a sociedade, e fui fazer download de sua versão 10.1.3 RC3 , para brincar um pouco... e tive a melhor surpresa de todos os tempos. JDeveloper se tornou uma ferramenta maravilhosa para desenvolvimento... além de free , ela conserva alguns aspectos que eu prezo em um aplicativo java de qualidade:

1 - Versatilidade no uso: Não é enrolado como algumas ferramentas livres
2 - Solução comercial já pronta para o uso: Você não precisa baixar 215 plugins , fazer 313 alterações nos XML da aplicação para ela se tornar READY TO USE em sua empresa , é só baixar e usar... já vem todo integrado , até mesmo com o OC4J , porem debuga em vários outros container
3 - Produto acabado para a comunidade e para as empresas: O que o JDeveloper é ? é sim um produto muito bem acabado , não é uma "previa do que vem por ae" como muitos "criadores de plugins" do eclipse fazem.

Inicialmente eu achei que estava exagerando... mas é simples... baixe você também, e teste o editor de "telinhas" (swing) , voce vai chorar de alegria... RÁPIDO E PODEROSO. A integração com containers J2EE ainda considero meio fraca , mas realiza o debug numa boa. JSF? inbutido por padrão , o melhor de tudo , tem reenderizadores para a tela, você vê o e escreve código JSF , semelhante ao Creator da Sun , porem muito mais tranqüilo , pois nao gera código proprietário.

A Unica coisa é que ele é bastante diferente de outros IDE's , realmente precisa aprender a mexer na criança antes de poder avaliar... mas acho que o pessoal do eclipse e do VEP vão ficar com inveja dos recursos

Gerenciamento de memória do Java

Em minhas andanças eu nao pude deixar de notar mais um ótimo "artigo" do pessoal da Argonavis sobre gerenciamento de memoria do Java 5 , bem... eu já fui em varias palestras do pessoal da argonavis... teve uma de WebServices que foi de dar sono... o cara explica TIMTIM por TIMTIM , mas no final dei valor pois existem varios pontos no funcionamento de algumas tecnologias que são essenciais para o entendimento da tecnolgia em questao , tudo em prol do endendimento HEHE.

Se você é daqueles que se interessa como as coisas funcionam , este PDF é para voce :)

Ajax - Solução dos Problemas ?

Muito se fala no tal do AJAX , tem gente que até chama de Web 2.0 a revolucao que o tal brinquedinho esquecido da MicroSoft anda fazendo pelas paginas web, sim ! a MicroSoft criou o Ajax a muuuuito tempo atraz , usou em alguns produtinhos e acabou esquecendo.

Agora com o resurgimento desta tenologia tem nego achando que é simplesmente botar essa nhaca na pagina e sair feliz... performance nem sempre é tudo... as vezes se sacrifica performance em favor de um código mais limpo e de fácil manutencao... Hibernate é um exemplo disso , JDBC direto é muito mais rapido... mas mesmo assim utilizamos um ORM para tornar a coisa toda mais "natural" ao aspecto OO.

Acho particularmente que o Ajax é uma boa alternativa se utilizado de forma conciente... separando a parte VISUAL do codigo propriamente dito... um belo exemplo disso é o framework padrao do J2EE , O JavaServer Faces... foi concebido para que você possa utilizar todo o poder do Ajax sem ter que mecher nenhuma linha do seu codigo... tudo isso apenas trocando sua implementacao. Como ele consegue isso ? simples... JSF é um padrao , nao um "framework" , entao hoje se você optar por utilizar a implementação da Apache , voce vai notar que o CORE está escrito na forma normal ( com refresh a cada submissao ) , mas existe alguns componentes em paralelo que utilizao Ajax para reenderizar ( pacote sandbox ) , muito interessante... mais ainda não suficiente... pois o que queremos é algo TRANSPARENTE , nada de programar com componentes especificos... queremos independencia nessa camada... existe uma implementacao que atende a estas espectativas... se chama AjaxFaces , ela implementa todo padrao em cima da comunicação via Ajax e a reenderizacao instantanea... é como trocar de sapato... nao requer pratica nem habilidade...

É isso que torna JavaServer Faces um framework melhor que qualquer outro... afinal... voce realmente tem independecia de fornecedor... se amanha seu cliente quiser pagar pelo AjaxFaces , muito bem... ele TEM OPCAO... agora se vc usar struts , tapestry, webwork2 vc esta condenado a esperar que os vendedores se mecham para adaptar.

Ajax é bom assim... transparente... tem alguns loucos que simplesmente jogao direto no JSP a chamada ao XMLHttpRequest e tratao tudo na mao... com gambiarras interminaveis de javascript e um codigo extremamente complexo de dar manutencao... como eu disse... loucos.

Oracle's ADF Faces donation to Apache

Interessante....

A Oracle é uma empresa no mínimo interessante !!! , após um ano de "compras" ela agora vem doar um produto que oferecia como GRANDE DIFERENCIAL de seu Application Server ( OC4J ), quem comprasse seu maravilhoso container java receberia uma "licenca" do ADF Faces. Mas isso não foi de uma hora pra outra... antes ela havia tornado "gratis" seu produto... uma estrategia que esta sendo adotada por muitas gigantes do software...

Sempre tive alguns problemas em aceitar tecnologias OpenSource , mas definitivamente tudo que vem da apache ( ou quase tudo ) tem se mostrado incrivelmente estavel e de performance razoavel... Me lembro quando conheci Hibernate , após um ano tomando no rabo utilizando o iptables do linux para filtrar pacotes e balancear a carga , aplicando dezenas de patches nao oficias , e me perguntando "olha q legal , prq nao tornaram oficial isto ?" cheguei a conclusao que meu processor de física estava certo:

Quem inventou a tartaruga ?
R: Deus
Tartaruga sobe em arvore ?
R: Nao...
Entao se ela estiver lá em cima... DEIXA ELA LÁ... PORQUE ALGUM MOTIVO TEM...

Entao... seguindo este raciocionio... meus sonhos com o software livre desabaram quando apliquei o tal do 7(seven) layers no kernel do linux... aquilo só me fez perder tempo e crer que software livre NEM SEMPRE é algo comercialmente viavel... as vezes é melhor comprar algo do que usar um patch em cima de uma coisa q nao foi projetada pra fazer o que se pede...

Hibernate me parecia mais uma daquelas "ferramentas opensource" que fazem tudo da "maneira dele" matando a portabilidade e fazendo com que voce fique nas maos de um alucinado que trabalha das 2 da madrugada até as 8... somente nos dias ímpares e em madrugada de lua cheia... Na epoca utilizava os "maravilhosos" Entity Beans e arriscava meu rabo por eles... até o dia que fui forçado a aprender esta ferramenta... afinal... em minha empresa tinha uns bobos da cabeça querendo utilizar JDBC direto em um projeto grande... ou seja... ter a independecia do java... e a macarronada do JDBC , sendo mais uam vez preso ao banco de dados escolhido inicialmente... Tanto Gavin viu a necessidade de padronizar sua ferramenta que elegeu Hibernta 3.1 como uma implementação da especificacao EJB 3.0, tornando ela usável em ambito corporativo.

Quem sabe o pessoal do tapestry nao aprende um pouco com o Gavin e nao tenta contribuir para evoluir o padrao do JSF invez de ficar criando um software que tem quase que o mesmo "lado escuro" do software fechado.... uma vez que vc faz tudo com ele... vc definitivamente CASA com a solucao.