Comentário interessante Java x Ruby

Só na cabeça de fanáticos Ruby tem condições de substituir qualquer coisa, e não é só isso, se alguém discorda é atacado verbalmente! Ou seja, é o marketing estilo “bully”, aquele que te pega de porrada se você discordar. Eu não sou fã de marketing de Java, mas nunca vi uma empresa ou um vendedor chamando seus possíveis clientes de “burros”, e daí para baixo, por não desejarem usar Java. hahahah

Mas o pior de tudo é contarem vantagem de “somos superiores”. Meu Deus do céu, sequer têm noção de que isso faz mais mal a própria causa do que bem. Parece que todos que usam Ruby ganham automaticamente um título de “Leonardo da Vinci da área de TI”.

Tem algum script GreasyMonkey que automaticamente da nota um para algum user?

Thiagosc:

Só na cabeça de fanáticos Ruby tem condições de substituir qualquer coisa, e não é só isso, se alguém discorda é atacado verbalmente! Ou seja, é o marketing estilo “bully”, aquele que te pega de porrada se você discordar. Eu não sou fã de marketing de Java, mas nunca vi uma empresa ou um vendedor chamando seus possíveis clientes de “burros”, e daí para baixo, por não desejarem usar Java. hahahah

Mas o pior de tudo é contarem vantagem de “somos superiores”. Meu Deus do céu, sequer têm noção de que isso faz mais mal a própria causa do que bem. Parece que todos que usam Ruby ganham automaticamente um título de “Leonardo da Vinci da área de TI”.

Verdade, você tem toda razão. Ruby é a maior besteira e só cretino usa.

Ruby é maneiro e eu estou querendo aprender.

Sei PERL e dizem que Ruby é o PERL state-of-the-art.

Um dos desenvolvedores do Python me confessou que Ruby é bem legal e praticamente admitiu que é melhor do que python.

A questão é que Ruby não vai dominar o mundo e desbancar Java por uma simples razão: não há espaço nem momentum para isso. É o que o cara fala no artigo.

Fiquei mais tranquilo ou perigosamente mais acomodado.

Sérgio, a questão não é dominar o mundo. É oferecer uma forma mais simples (você já deve ter percebido isto pelo que tenho visto em seus posts) de fazer o que é feito atualmente em Java.

Acredito que mais simples é subjetivo. Não há uma métrica fixa para medir isso. Eu acho que coisas quick’n dirty não são simples por causa da manutenção no futuro, mas tem gente que acredita que desenvolver uma estrutura de classes coerente de forma que auxilie os desenvolvedores é “perda de tempo” ou complexidade.

Parece alguns desenvolvedores que eu conheço, parece que eles gostam de competir para ver quem faz um software em menos linhas, isso para eles é “simples”. No final das contas o resultado não é bom, especialmente depois de alguns anos quando o aplicativo já passou pela mão de uns 4 desenvolvedores. Fica uma caca…

Além do mais o fato de ser mais simples não é suficiente para algo “pegar”. O Java surgiu na mesma época que a internet para uso de usuários comuns, e como o autor do blog disse, não há nada novo que impulsione o Ruby, é o mais do mesmo.

ruby tem um forte apoio da metolodologia ágil, se java fosse focado um bocado nisso não tem pq mudar pra ruby

louds:

Thiagosc:

Só na cabeça de fanáticos Ruby tem condições de substituir qualquer coisa, e não é só isso, se alguém discorda é atacado verbalmente! Ou seja, é o marketing estilo “bully”, aquele que te pega de porrada se você discordar. Eu não sou fã de marketing de Java, mas nunca vi uma empresa ou um vendedor chamando seus possíveis clientes de “burros”, e daí para baixo, por não desejarem usar Java. hahahah

Mas o pior de tudo é contarem vantagem de “somos superiores”. Meu Deus do céu, sequer têm noção de que isso faz mais mal a própria causa do que bem. Parece que todos que usam Ruby ganham automaticamente um título de “Leonardo da Vinci da área de TI”.

Verdade, você tem toda razão. Ruby é a maior besteira e só cretino usa.

Por favor, bote a mão na consciência e responda honestamente:

• Onde está escrito isso?

Para você é tudo 8 ou 80? Se eu não concordo contigo, então significa que eu te acho um cretino? É exatamente esse tipo de comportamento, o marketing estilo “bully”, o qual eu me refiro.

Não, esse é o estilo don’t feed the troll.

A justifica para a tipagem forte do Java é que é menos error-prone e mais recomendável para aplicações robustas. Só que tipagem dinâmica te dá muito mais produtividade e flexibilidade e a maioria das aplicações java no mercado são server-side/web applications. Mas também existe banco de dados feito em Java, e outras aplicações robustas que talvez uma tipagem dinâmica não cairia bem.

Então ruby seria mais recomendável para aplicações web mesmo. Já o Ruby on Rails não pode ser feito em Java ??? Java on Rails ???

O problema de partir para o Ruby é abandonar toda a infra-estrutura, credibilidade, mercado, documentação, suporte, comunidade, etc que Java te dá.

Não é porque ruby é pior ou melhor do que Java. A questão não é essa e acho que para o que eu gosto de fazer, que é projetos web, ruby é melhor que java por ser mais pragmática e dinâmica. A questão é: o que eu vou ganhar fazendo sites com Ruby On Rails ??? Produtividade ???

Eu realmente acho que o grande hype do RoR se deve muito mais aos frameworks super-complicados, improdutivos, cheios de XML e low-level que estão por aí do que aos méritos do RoR em si.

Hoje mesmo conversando com um companheiro do trabalho que usa python + cgi para desenvolvimento web ele falou: todos os frameworks se dizem simples mas não são. Todos possuem uma curva de aprendizado grande.

O objetivo do Mentawai é mudar isso. Se estamos conseguindo ou não é outra história, mas estamos focados PRINCIPALMENTE E UNICAMENTE nisso. Se não está fácil então precisamos de feedback da comunidade para fazer com que fique.

Será que é impossível fazer um framework web totalmente simples e alto-nível (= high-level ou seja com um alto nível de abstração dos problemas) em Java ???

Outra coisa: Java precisa urgentemente de um ActiveRecord. Hibernate é muito poderoso e robusto, mas não é simples nem fácil !!!

É complicado porque Java não te da toda as facilidades que Ruby oferece (closures, blocks, etc). Mas que estão tentando, estão.

https://trails.dev.java.net/
http://grails.codehaus.org/

Leitura recomendada:
http://www.artima.com/weblogs/viewpost.jsp?thread=77745

cuidado tb com o paradoxo da teoria da mudança

É complicado porque Java não te da toda as facilidades que Ruby oferece (closures, blocks, etc). Mas que estão tentando, estão.

https://trails.dev.java.net/
http://grails.codehaus.org/

Leitura recomendada:
http://www.artima.com/weblogs/viewpost.jsp?thread=77745

que avatar mais estranho é esse cara :roll:

Mais cuidado ainda com o Senso Comum™

Olá

Dois comentários sobre o artigo:

1. Sobre Fortran

Por força de estar sem trabalho com Java peguei um trampo de manutenção de antigos sistemas da cálculo estrutural feitos em Fortran ainda no tempo dos mainframes e que posteriormente converti para Micro na era do DOS e Windows 3.1

Descobri que o Fortran evoluiu muito e que agora até orientação a objetos tem nas versões mais novas. Uma das coisas curiosas que descobri é poder usar o Eclipse 3.1.1 para desenvolver com Fortran usando os plugins do Photran.

2. Sobre a frase [color=darkblue]“There is nothing a RoR web site can do that a Java web site cannot”[/color]

Desconfio que a frase talvez pudesse ser dita assim: [color=darkblue]“There are many things a RoR web site can do before the start of a Java web site”[/color]

Não sei Ruby, nunca usei Rails mas faz tempo que venho me interessando por ele e lendo muito sobre o assunto. Apesar de correr riscos de escrever bobagens, vou resumir o que eu entendi a partir de ler e ouvir gente ligada ao Java que tem usado Ruby:

:arrow: Ruby e RR atuais ainda não podem ser considerados como o grande próximo passo no desenvolvimento de sistemas, principalmente para sistemas corporativos.

:arrow: Mas Ruby e RR mostram que há um modo mais fácil de se fazer as coisas fáceis e este é o caminho que deverá ser seguido no futuro;

:arrow: Ruby e RR deixam claro que Java, como é atualmente, é pesado demais para coisas que precisam de uma solução rápida e direta e que isto precisa de algum jeito ser mudado, sob pena de perder mercado.

:arrow: Na medida que os caras acham que Ruby não será a última Coca Cola do deserto, estes mesmos caras dizem que o que está por vir por aí de bom e ágil, seja Java, Ruby ou qualquer outras coisa, com certeza seguirá pegadas do Ruby e RR

:arrow: Uma das conclusões deles é que para grandes sistemas corporativos o Java ainda será soberano, principalmente enquanto não aparece o SOAonRails. Apesar de muitas empresas não gostarem de POJOS e preferirem todas as complicações que alguns teimam em enfiar usando tudo que começa com EJB (mesmo o 3.0 que pensando bem tem mais sentido para quem já usa EJB poder cortar código)

:arrow: Porém, para sistemas pequenos que precisam de soluções ágeis, o Java é over. O futuro poderá estar nos scripts ou o futuro poderá estar em um Java On Rails. Mas certamente o futuro desta faixa de problemas não estará ao lado deste Java que conhecemos. Pode ser até que a Microsoft abocanhe esta fatia.

[]s
Luca

Me dê mais um mês brincando com EJB 3 e o Entity Manager que eu garanto que ninguém mais vai dizer isso

É só eu ter tempo de escrever o maldito tutorial…

Olá

Isto tenho lido e ouvido por aí. E também que Java precisa se livrar de vez dos EJBs. Tem gente simpática ao EJB 3.0 só porque cortou muita coisa de ruim. Eu ainda estou cético e depois que li que a especificação do EJB 3.0 tem 700 páginas fiquei horrorizado. Se isto for verdade acho que trocar Spring + POJOs + algo que pode ser mentawai por qualquer coisa que contenha em sua formulação química a sigla EJB, continuará sendo matar pombo com bazuka (antes era com canhão).

[]s
Luca

O Spring, no fim das contas, termina utilizando EJB pela JPA

Session beans ainda são uma porcaria, mas os entities, que são o “Hibernate com MUITO MENOS configuração” não tem nem comparação. Não dá pra dizer que é “tão simples quanto” o ActiveRecord, mas que já a coisa já melhorou muito, melhorou sim.

Luca:

Olá

Isto tenho lido e ouvido por aí. E também que Java precisa se livrar de vez dos EJBs. Tem gente simpática ao EJB 3.0 só porque cortou muita coisa de ruim. Eu ainda estou cético e depois que li que a especificação do EJB 3.0 tem 700 páginas fiquei horrorizado. Se isto for verdade acho que trocar Spring + POJOs + algo que pode ser mentawai por qualquer coisa que contenha em sua formulação química a sigla EJB, continuará sendo matar pombo com bazuka (antes era com canhão).

[]s
Luca

Sem querer ser chato, mas já sendo, você já trabalhou com um sistema realmente distribuído com EJB? Foi feliz com isso?

Se você foi, precisa, urgentemente dar uma olhada na API de remoting do Spring e ver como se faz uma camada de chamadas remotas realmente separada de todo o resto.

Olá

Pois é, nestes casos admito que são ótimos e vale a pena pagar seu preço (*). Mas todo mundo sabe de casos que em se usou EJBs apenas para aprender ou para justificar a compra de um Websphere da vida e que o sistema ficou pesado demais desnecessariamente. A imagem do Java vai lá para baixo. Um dia, há uns 2 anos atrás em um almoço de negócios, um diretor de uma empresa grande deu risada na minha cara dizendo que Java não prestava porque uma empresa que ele conhecia tinha gasto mais de 20 milhões com Java, Websphere, máquinas IBM, etc. e tal e depois de um ano não tinha resultado nenhum.

(*) Digo por ouvir dizer porque nunca passei por isto

[]s
Luca

Começando a dar sinais de mudanças…
http://www.jroller.com/page/obie?entry=thoughtworks_on_rails_enterprise_adoption

Fabrício Cozer Martins:

Luca:

Olá

Isto tenho lido e ouvido por aí. E também que Java precisa se livrar de vez dos EJBs. Tem gente simpática ao EJB 3.0 só porque cortou muita coisa de ruim. Eu ainda estou cético e depois que li que a especificação do EJB 3.0 tem 700 páginas fiquei horrorizado. Se isto for verdade acho que trocar Spring + POJOs + algo que pode ser mentawai por qualquer coisa que contenha em sua formulação química a sigla EJB, continuará sendo matar pombo com bazuka (antes era com canhão).

[]s
Luca

não fale assimm … EJB tem seu uso em ambientes distribuídos.

Jini tem uso em ambientes de objetos realmente distribuídos (distribuídos de verdade, não este paradigma estúpido “distribuídos-mas-centralizado-no-appserver” dos EJBs) com uma simplicidade e performance bem satisfatórias. Web services são mais efetivos para ambientes distribuídos pois são independentes de tecnologia do ponto de vista de quem os consome. EJBs nem tanto. Normalmente (70% dos projetos em que eu já participei), ninguém usa EJB remotamente porque a performance cai drasticamente (http://jboss.org/jbossBlog/blog/acoliver/2006/03/21/If_you_dont_do_this_JBoss_will_run_really_slowly.txt) e fazer tuning em AS para conseguir recuperar o prejuízo não é algo tão simples e bem documentado como fazer tuning em um banco de dados (pelo menos dizem por aí que é bem documentado).
Então, nem para ambientes distribuídos EJBs são a melhor escolha. Não estou querendo dizer que EJBs de nada valem, mas eles não costumam ser a melhor alternativa para a maioria dos projetos que os utiliza.
Mas, bla bla bla à parte, e voltando ao novo tópico desta semana sobre o debate “Java vs. Ruby”, concordo quando dizem que Ruby talvez não vá vingar como Java vingou, mas Ruby ajudou a dizer ao javaneses que o “Rei Java está nu”, mostrando quão complexo está se tornando nosso ambiente para resolver problemas simples. E acho que esta é a lição mais importante que a comunidade Java deveria tirar destes debates.

hibernate complicado? po pessoal… hibernate com criteria e anotacoes do JPA é mais facil que o active record… sem contar q vc pode controlar um BOLO de coisas… soh se quiser

luca… nao entendo o pessoal que fala do Spring. o manual do Spring deve ser umas TRES vezes maior que a spec de EJB3. Sem contar que o Spring hoje em dia eh um framework-faz-tudo… enquanto ta todo mundo no “less is more” o Spring vai enfiando mais e mais “suporte” a apis

é RIDICULo quando o Spring vfala que tem suporte a api de email e o que ele faz é simpelsmente injetar um bean idiota que encapsula o mail…

Maurício Linhares:

Session beans ainda são uma porcaria, mas os entities, que são o “Hibernate com MUITO MENOS configuração” não tem nem comparação. Não dá pra dizer que é “tão simples quanto” o ActiveRecord, mas que já a coisa já melhorou muito, melhorou sim.

porque uma porcaria? nao tem mais home, voce nao precisa implementar metodos de lifecycle se nao quiser, é um POJO e encapsula uma logica de negocios…

EJB3 vai estourar se BEA e IBM nao demoraram 3 anos para seguirem a spec e atualizarem os servers…

Só se o Hibernate mudou muito, pois o quick-start dele não era nem um pouco quick. Por isso que até hoje eu uso JDBC.

Ter um monte de coisa no framework não é ruim, desde que essas coisas possam ser facilmente ignoradas por quem não quiser elas. Veja o java, tem um milhão de coisas e nem por isso é complicada…

Alguém aqui manja de ActiveRecord ???

O quão difícil seria fazer um em Java ???

No passado eu sei muito um DBBean que fazia CRUD automático sem uma linha de SQL.

Funcionava direitinho e ainda era otimizado para só dar update nos campos que foram alterados e não em tudo.

Sem querer ser chato, mas já sendo, você já trabalhou com um sistema realmente distribuído com EJB? Foi feliz com isso?

Se você foi, precisa, urgentemente dar uma olhada na API de remoting do Spring e ver como se faz uma camada de chamadas remotas realmente separada de todo o resto.
Sabemos o quanto ainda é difícil trabalhar com ambiente distribuído, o principal pra mim é a rede, alguns culpam o Java por ser lento em ambiente distribuído, mas será que eles ja pararam pra ver se não é o tráfego da rede que está tornando lento o sistema ? Ao invés de sair por aí dizendo que EJB é lento, que não presta , que isso que aquilo … A única dificuldade que se tem quando vc está num ambiente desses é fazer com que fabricantes de appServers se comuniquem eficientemente, que não acontece muito bem hoje em dia, o Spring apresenta um conceito interessante sobre invocações remotas que com EJB utiliza-se alguns patterns auxiliares como BD, SL, etc… para isso. Acredito no EJB3, está mais simples do que a porcaria da #$$%&$ da esp. 2.1

Paulo Silveira:

porque uma porcaria? nao tem mais home, voce nao precisa implementar metodos de lifecycle se nao quiser, é um POJO e encapsula uma logica de negocios…

saoj:

Outra coisa: Java precisa urgentemente de um ActiveRecord. Hibernate é muito poderoso e robusto, mas não é simples nem fácil !!!

Geralmente o problema de aplicações distribuídas está na arquitetura das aplicações. A Primeira Lei de Objetos Distribuídos de Fowler é largamente ignorada pelo senso comum.

Session Beans como remote façades são bem razoáveis, o ponto é que muito raramente você rpecisa de remote façades. Mesmo quando precisa, é preciso que o EJB seja apenas isso: uma façade. Nada de lógica dentro dele.

Não acho que o Hibernate em si seja simples, mas é muito mais fácil desenvolver com Hibernate do que com JDBC puro, em minha opinião.
Mapeamento Objeto-Relacional não é trivial de se implementar corretamente, principalmente com os diversos recursos do Hibernate.

O que é chato é algumas particularidades que você as vezes quebra a cabeça para resolver, principalmente quando se tem relacionamentos entre entidades.

Mas é algo que se você teve problema uma vez, aprende e nunca mais comete o mesmo erro. É um projeto muito bem documentado.
Demora um pouco para se aprender a usar, mas vale cada segundo gasto.

Um dos problemas com sistemas em ambiente distribuídos também é que o pessoal não consegue estabelecer corretamente os requisitos, não sabe ao certo o que acontecerá, só dizem … é possível que nós poderemos crescer e ser necessário colocar componentes de forma distribuída, é possível que existam clientes solicitando serviço sob demanda e com isso será mais eficiente se tivermos uma máquina mais perto dele geograficamente provendo esse serviço, ou seja, tudo gira em torno das possibilidades e não das factibilidades.

Shoes, em seu artigo:

Concordo com vc, mas um problema que vejo é: como tirar isso da cabeça das pessoas se ao procurar exemplos na Internet, a grande maioria destes usam DTOs/VOs/TOs. Aposto que vc já parou para pensar: “Poxa! as vezes tenho impressão que estou dando murro em ponta de faca, pois eu falo e o pessoal não me entende ou não aceitam!”, mas não é fácil mudar essa cultura se ao começar a programar em Java, os exemplos que vc vai encontrar são destes tipos!

ASOBrasil

Não, esse é o estilo don’t feed the troll.

Esse é o “fórum de uma idéia só”. Cante conforme o coro ou seja xingado.

Thiagosc:

Esse é o “fórum de uma idéia só”. Cante conforme o coro ou seja xingado.

Você não precisa participar do fórum. Pode fechar o página e nunca mais voltar

louds:

Thiagosc:

Só na cabeça de fanáticos Ruby tem condições de substituir qualquer coisa, e não é só isso, se alguém discorda é atacado verbalmente! Ou seja, é o marketing estilo “bully”, aquele que te pega de porrada se você discordar. Eu não sou fã de marketing de Java, mas nunca vi uma empresa ou um vendedor chamando seus possíveis clientes de “burros”, e daí para baixo, por não desejarem usar Java. hahahah

Mas o pior de tudo é contarem vantagem de “somos superiores”. Meu Deus do céu, sequer têm noção de que isso faz mais mal a própria causa do que bem. Parece que todos que usam Ruby ganham automaticamente um título de “Leonardo da Vinci da área de TI”.

Verdade, você tem toda razão. Ruby é a maior besteira e só cretino usa.

Olha, acho que o amigo foi infeliz na frase onde se refere que só cretino usa Ruby. Programo em Java, C/C++, PHP e como também programo em Ruby, essa afirmação me ofendeu. Acho isso muita falta de respeito com profissionais sérios que utilizam outras linguagens ALÉM DO JAVA, seja para trabalhar, por hobby ou simplesmente curiosidade. Aliás, acredito que se alguém deseja ter uma boa colocação no mercado e ser competitivo, precisa conhecer novos horizontes, além daquele mostrado pela TV. Isso é fundamental em qualquer área que se atue, em qualquer profissão. Agora, porque você não concorda com o que é dito sobre Ruby ou não aprova a forma de agir de alguns profissionais, isso também não te dá o direito de ofender/diminuir os demais. Você condenou a atitude de alguns profissionais mas fez algo bem pior. E as atitudes de “Leonardo da Vinci de TI” não se aplica somente aos Rubystas. Tem muito profissional de Java, C#, PHP agindo da mesma maneira. Defendendo sua tecnologia com unhas e dentes e se esquecendo que, quem dita as regras é o mercado. Quando o Java saiu, tinha muita empresa e profissional acreditando que não ia dar em nada, que Java não prestava. Imagina se Ruby acaba dando “em nada” como o Java.

Cara, pelo amor de Deus, não deu pra perceber que ele fez uma ironia? Não precisa gastar essa energia toda.

Estava sendo irônico, cínico. Eu uso Ruby profissionalmente, e acho muito melhor que Java muitas tarefas.

Como você pôde perceber existe um grupo de extremistas aqui no fórum preparados para ofender a todos que discordem de seus pontos de vista míopes.

Você se esquece de um detalhe importante, Ruby é mais velho que Java. Ou seja, o Java evoluiu mais rápido do que ele, por que? Não apenas Ruby, mas Python e várias outras linguagens, por que será?

Não há uma demanda do mercado para isso, apenas meia dúzia de fanáticos fazendo barulho. E Ruby sequer conta com coisas básicas necessárias a qualquer negócio na era da internet como suporte a unicode, internacionalização, etc.

É até engraçado ver os “Leonardos da Vinci de TI” se descabelarem para provar que alguma coisa presta nesse negócio. Em contrapartida eu jamais ouvi um profissional Java xingar outros de burros ou coisa parecida por pensar diferente.

http://www.globalize-rails.org/

Period.

uma pergunta meio tola, mas o Ruby dá suporte a transações distribuídas, replicação de sessão, e toda a parafernália que o Java com o RMI, JNDI, EJB, etc … oferece ?

Tem suporte a Web Services ? Tem alguma API pra programar pra Celular ?

Tem algum mecanismo de persistência fora a convenção dele ?

Hum, acho que não. Mas acho que você usou o termo errado:

michaelis:

pa.ra.fer.ná.lia sf (lat med paraphernalia)
1 Objetos pessoais. 2 Equipamento necessário a uma atividade humana. 3 Pertences; tralha.

Opa, ActionWebService @ http://api.rubyonrails.com/

Fabrício Cozer Martins:

Tem alguma API pra programar pra
Celular?

Como você pôde perceber existe um grupo de extremistas aqui no fórum preparados para ofender a todos que discordem de seus pontos de vista míopes.
Bora deixar a brincadeira mais interessante. Cite os nomes dos extremistas aqui no fórum, dê os links para os tais post com opiniões extremas, explique por que é uma opinião alienada e dê o seu ponto de vista. Dizer “há um grupo de extremistas aqui no fórum” é bastante subjetivo, quero aprender a separar o joio do trigo também e é importante saber o que é “extremismo” e o que é a realidade.

Não precisa citar os seus posts.

Já que você não se vê como contra-exemplo pra essa afirmação, todo mundo aqui no GUJ trabalha com Java e você não para de dizer que nós ficamos irritadinhos quando alguém discorda dagente. Muita contraditório isso não acha?

Fabrício Cozer Martins:

uma pergunta meio tola, mas o Ruby dá suporte a transações distribuídas, replicação de sessão, e toda a parafernália que o Java com o RMI, JNDI, EJB, etc … oferece ?

Tem suporte a Web Services ? Tem alguma API pra programar pra Celular ?

Tem algum mecanismo de persistência fora a convenção dele ?

Seria ótimo fazer uso da parafernália da J2EE usando uma linguagem com recursos mais avançados (blocks, closures, collections de verdade…) e de nível mais alto.

plentz:

Fabrício Cozer Martins:

Tem alguma API pra programar pra
Celular?

Não.

Talvez seja uma questão de tempo… Tem até Python para celular…

Fabrício Cozer Martins:

uma pergunta meio tola, mas o Ruby dá suporte a transações distribuídas, replicação de sessão, e toda a parafernália que o Java com o RMI, JNDI, EJB, etc … oferece ?

Tem suporte a Web Services ? Tem alguma API pra programar pra Celular ?

Tem algum mecanismo de persistência fora a convenção dele ?

Algumas dessas parafernálias não faz sentido Ruby ter, tais como JNDI, RMI e EJB, já que são técnologias específicas ao Java. JNDI é uma API muito genérica de diretórios, não possui equivalente direto em Ruby, mas coisas como acessar um servidor LDAP é sim possivel. Existe suporte a comunição remota em Ruby, que seria o moral equivalente ao RMI. Quanto a EJB, dado o enorme escopo dessa sigla, não existe resposta simples, quais partes do EJB vc gostaria de ver em Ruby?

Replicação de sessão é uma forma de gerenciar sessões em um cluster, RoR faz isso facilmente.

Transações distribuidas, bom, isso parece mais ser um argumento de vendedor que um argumento real. Sério, quantos aqui realmente precisaram usar XA e 2PC? Eu pessoalmente só usei quando o arquiteto do projeto achou que ia ficar bonito no currículo dele ter projetado algo que usasse isso. Uma transação distribuida possui mais estados bizantinos intrinsecos que normalmente um sistema teria ser usá-las.

Se teu sistema precisa de coisas que Ruby não suporta, use Java, se teu sistema possui requisitos simples e não tem muita coisa bizarra para ser resolvida, provavelmente Ruby é uma solução mais produtiva. Isso é ser pragmático, saber dizer que as duas técnologias são uteis e uma não se sobrepoe a outra integralmente.

louds:

Isso é ser pragmático, saber dizer que as duas técnologias são uteis e uma não se sobrepoe a outra integralmente.

Se é para ser pragmático eu levaria em consideração vários outros fatores, até porque se um projeto usa determinada plataforma TODOS os programadores envolvidos são obrigados a conhecer aquilo.

Isso sem contar ferramentas, código já existente, perspectiva de evolução da plataforma e do negócio, etc.

Parece fácil “use o que for melhor”, agora imagine um desenvolvedor que resolve usar 5 diferentes coisas em 5 projetos diferentes e depois de alguns meses ele sai para ganhar mais em outro lugar, você acha que será fácil encontrar pessoas com experiência em 5 plataformas diferentes?

É necessário ter um plano estratégico em TI, o que a empresa pretende a curto, médio e longo prazo, e escolher aquilo que se adequa mais aos planos.

Acho que o “pragmatismo” vai além do código, o que as líderes de torcida do opensource parecem não entender. Acho que pensando dessa forma Ruby teria uma chance, mas infelizmente alguns só pensam em bits e bytes.

Será? Aqui é claro a distinção entre fanboys e profissionais com uma visão pragmática das coisas. “Pragmático”, essa palavra que alguns gostam de repetir, é justamente o que eles menos praticam.

Thiago, mas você vê nenhuma semelhança entre o seu pensamento e o do pessoal da época do Cobol não?

Pelo menos você tá parecendo admitir que se tratanto de bits e bytes o Ruby pode ser uma solução melhor que Java, mas gerencialmente ainda é complicado para uma equipe adotar a ferramenta.

Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.

Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…

Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença.

Eu acho falha essa idéia que desenvolvedores devem trabalhar com uma linguagem apenas. De fato, um desenvolvedor Java provavelmente deve saber também shell script, dezenas de dialétos de xml, perl, etc. Se ele já sabe isso, qual o problema de saber também C#, C++ e Ruby. E qual o problema de ele usar a mais adequada para cada situação?

Esquecendo Ruby por um segundo, ser fluente em várias linguagens de programação cada dia é mais util a medida que todos realizam que cada
uma tem um nicho no qual é melhor que as demais.

e os sintomas de Rails se espalhando [ http://www.theserverside.com/news/thread.tss?thread_id=41189 ]

Me dê mais um mês brincando com EJB 3 e o Entity Manager que eu garanto que ninguém mais vai dizer isso

É só eu ter tempo de escrever o maldito tutorial…

Opa… contamos com isso

É praticamente impossível ter um ActiveRecord, assim como todo Active*, em Java. Seria necessário que o Java fosse uma linguagem dinámica para isso.

As coisas podem mudar, mas hoje é praticamente impossível. O melhor que se pode chegar é mesmo JPA ou Hibernate com annotations.

[]s

louds:

Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.

Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…

Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença.

Eu também, alias na maioria delas. E as poucas que conheci que tentavam padronizar uma única tecnologia. Acaba falhando ou gastando horrores em casos aonde aquele tecnologia não era a mais indicada e for teimosia usaram a padronizada.

juzepeleteiro:

saoj:

Alguém aqui manja de ActiveRecord ???
O quão difícil seria fazer um em Java ???

É praticamente impossível ter um ActiveRecord, assim como todo Active*, em Java. Seria necessário que o Java fosse uma linguagem dinámica para isso.

As coisas podem mudar, mas hoje é praticamente impossível. O melhor que se pode chegar é mesmo JPA ou Hibernate com annotations.

[]s

Impossível não é. Daria para alcançar o mesmo efeito do ActiveRecord usando Dynamic Proxies e uma porrada de reflection. Mas o trabalho necessário talvez inviabilizasse.

De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.

Não é a mesma coisa que o ActiveRecord.

Esses tópicos de versus sempre são muito interessantes, mas nunca chegam a lugar algum, hehehehe. Me lembra muito os eternos C x C++, C# x Java, Maçãs x Laranjas…

Mas isso é porque vocês não conhecem linguagens mais modernas e fáceis de usar, como Whitespace, Chef ou, a mais legal na minha opinião, COW! Depois de conhecer elas garanto que sua vida não será mais a mesma, ahhahaha

flw

Até então eu estou achado esse tópico bastante construtivo. Estamos conversando se é o não é possível ter ActiveRecord no Java; se o Ruby (que já é um realidade, assim como Java e .NET) vai crescer ou não no mercado enterprise, conversando sobre ser pragmatico e escolher a ferramenta certa para o projeto, se uma empresa deve ou não utilizar uma única tecnologia…

Não, esse não me parece um tópico Maças x Larajanjas… Me parece um tópico bem contrutivo… até então.

Dá ou não dá para ter ActiveRecord em Java ???

Alguém poderia postar um exemplo de como ActiveRecord funciona na prática ?

Talvez se fizéssemos isso não seria o pior dos mundos:

public class Person extends DBBean {

   private int id;
   private String username;

}

Person p = new Person(12);

p.load();

p.setUsername("sergio");

p.save();

p.delete();

Ok. Eu sei que o bean Person não é puro, pois está tendo que herdar de DBBean. Mas talvez isso não seja o fim do mundo e vai resolver o problema.

O problema é como pegar os campos de Person, sem ter que explicitamente defini-los no objeto, como eu fazia antes:

public class Person extends DBBean {

   private DBField id = new DBField(this, "id", DBType.INTEGER);
   private DBField username = new DBField(this, "username", DBType.STRING);

}

Assim vai funcionar bonito, mas tá longe de se parecer com ActiveRecord. Não é nem um pouco “puro” tb.

Alguém tem alguma idéia ou isso em Java vai ser complicado mesmo ?

[color=red]Deve ter alguma maneira de o DBBean se virar via reflection para descobrir os campos do Person, que está herdando DBBean. Nem que tenhamos que usar um marcador nesses campos.[/color]

private int _id;

private String _username;

saoj:

Dá ou não dá para ter ActiveRecord em Java ??? Alguém poderia postar um exemplo de como ActiveRecord funciona na prática ?

Claro, imagine que você têm uma tablea chamada clientes, com os campos id, nome, nascimento. No ActiveRecord seria:

class Cliente < ActiveRecord::Base
end

Agora digamos que você quer ter certeza que o campo nome e nascimento sejam preenchidos.

class Cliente < ActiveRecord::Base
    validate_presence_of :nome, :nascimento
end

obs: Existe vários validade_ e você ainda pode fazer os seus.

Agora, digamos que vc crie uma tabela "pedidos", aonde tem um foreing key para cliente (cliente_id).

class Cliente < ActiveRecord::Base
    validate_presence_of :nome, :nascimento
    has_many :pedidos
end

class Pedido < ActiveRecord::Base
    belongs_to :clientes
end

Por default já existe um método find generico, mas você pode escrever seus proprios finds. Exêmplo:

class Cliente < ActiveRecord::Base
    def self.find_by_nome(user_name)
        find(:all, :conditions => [ "name = ?", user_name])
    end

   def self.find_by_id(user_id)
        find(:first, :conditions => [ "id = ?", user_id])
   end
end

Obs: O ActiveRecord já tem como fazer load por id, mas eu criei esse só pra exemplifica a diferença entre :all e :first.

E o mais legal são os acts_as, aonde vc pode dizer o comportamento daquela entidade (pode ser tree, taggable, searchable, etc...). Que você define assim:

class Artigo < ActiveRecord::Base
  acts_as_searchable
end

Artigo.fulltext_search('ruby AND java')

Outro legal é o acts_as_taggable, que se não me engano é mantido pelo CV.

E é fácil criar os seus próprios acts_as.

E tem mais, tem por exemplo os campos created_at e updated_at, que se tiver na sua tabela ele preenche automaticamente.

Bom, qualquer error ai, perdão. Eu ainda sou muito novato em Ruby (pra ser honesto, terminei de ler o capitudo sobre ActiveRecord ontem).

obs: Tudo é guiado por padrão, e se o padrão que vc usa não é esse, você pode configurar (tanto o seu padrão, quanto o resto).

http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping

Isso parece muito com Hibernate, com a diferença é que vc não precisa definir/configurar nenhuma campo.

saoj:

http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping
Isso parece muito com Hibernate, com a diferença é que vc não precisa definir/configurar nenhuma campo.

Mesmo assim não é ActiveRecord, só é parecido. Os metodos de find,save,delete não estão no tipo, ainda precisa de um DAO. Não é dinámico, você precisa definir as variáveis e os gets e sets. Não têm acts_as, validade_ e eu não consigo imaginar como deve ser relacionamentos entre classes.

Mas não deixa de ser uma solução legal, mas ainda não é tão fácil é produtiva quanto ao ActiveRecord.

Como eu disse antes, é impossível se ter ActiveRecord no Java, por causa do próprio Java. Isso não é uma coisa ruim.

Lembre-se, ActiveRecord é só um detalhezinho do Rails, tem ainda um bocado de coisas que o fazem muito bom para aplicações web database-driven.

Mas, certamente não é nenhuma bala de prata.

Sim. Isso está mais para Hibernate sem configuração do que para ActiveRecord.

O meu DBBean está mais para ActiveRecord porque o save/load/delete estão no tipo.

Vc não precisa definir as variáveis no ActiveRecord ???

public class Person {

private int id;

private String username;

}

Não, não precisa. O que torna ele bem iterativo. Se algum campo novo aparecer, é só criar na tabela.

Os códigos que postei no exêmplo estão completos.

Ok. Legal isso. Mas onde vc define em que banco/connection/tabela ele deve pegar os campos do bean ?

Isso eu acho que é a questão do Convention over Configuration. Ele deve pegar como padrão tabelas com o mesmo nome da classe, colunas com o mesmo nome dos atributos, etc. Já o servidor e o nome do banco você tem que configurar, se não me engano.

O rails têm uma estrutura de diretórios padrão (veja aqui essa estrutura), e existe um arquivo /config/database.yml aonde você configura três banco, um para desenvolvimento, um para testes e um para produção.

O arquivo é mais ou menos assim:

development: adapter: mysql database: noc_dev host: localhost username: root password: test: adapter: mysql database: noc_tests host: localhost username: root password: production: adapter: mysql database: noc host: localhost username: root password:

saoj:

public class Person extends DBBean {

   private DBField id = new DBField(this, "id", DBType.INTEGER);
   private DBField username = new DBField(this, "username", DBType.STRING);

}

Assim vai funcionar bonito, mas tá longe de se parecer com ActiveRecord. Não é nem um pouco "puro" tb.

David:

saoj:

public class Person extends DBBean {

   private DBField id = new DBField(this, "id", DBType.INTEGER);
   private DBField username = new DBField(this, "username", DBType.STRING);

}

Assim vai funcionar bonito, mas tá longe de se parecer com ActiveRecord. Não é nem um pouco "puro" tb.

Pode funcionar, mas bonito eu não achei nao... :D

Sim. Funciona mas não é bonito nem puro. É isso que estamos querendo evitar aqui.

Pensando algo rápido:

public class Person extends DBBean {


}

Daí o DBBean descobre por reflection o nome da classe (Person), recebe uma connection por IoC, vai no banco, pega os campos da tabela, constroi uma lista de DBFields, cacheia isso, etc e tal.

Estaríamos chegando mais perto do ActiveRecord assim, creio eu..

Exato. Nome da classe no singular, nome da tabela no plural. Nome dos atributos igual ao nome das colunas. Tipos idem. Chave primaria eh “id” por default. E assim por diante. Se voce usar o padrao dele, funciona sem configurar nada. Mas voce pode configurar se nao gostar do padrao (eu p.ex., prefiro nome das tabelas no singular).

Agora, isso nem eh o mais interessante. Os finders automaticos e os relacionamentos que ele cria, p.ex., sao muito uteis.

Dados de conexao do banco (tipo, host, banco, usuario, senha) precisam ser configurados (tem um arquivo especifico pra isso, config/database.yml, basta abrir e alterar).

Marcio Kuchma

saoj:

Pensando algo rápido:

public class Person extends DBBean { }

Daí o DBBean descobre por reflection o nome da classe (Person), recebe uma connection por IoC, vai no banco, pega os campos da tabela, constroi uma lista de DBFields, cacheia isso, etc e tal.

Estaríamos chegando mais perto do ActiveRecord assim, creio eu…

Não, ainda falta os gets e sets, os finds… Java não é uma linguagem dinâmica. Falta os acts_as_ or validades_…

Já o Grails, é uma solução bem legal também. Pelo menos na teoria (eu nunca utilizei).

Não é necessário ter getters e setters. Eu até prefiro que não tenha. Por que não acessar diretamente os atributos private? O Hibernate, por exemplo, permite fazer coisas assim.

Entendi. Teria que criar os sets/gets dinamicamente, e isso não dá em Java, certo ?

A não ser que alterássemos o byte code em tempo de execução tipo JDO.

Alguém aqui tem experiencia com isso ?

Sim, mas para utiliza-los eles teriam que ser publicos (ou protected) ou ter get/set. De qualquer forma você têm que definir os atributos.

Mas, em Java, não utilizar get/set pode ser problema. Os frameworks que você vai utilizar esperam que haja get/set para seu attributos. (Um SpringMVC da vida, até mesmo o Struts). Ao não ser que você não exponha as suas entidades pro seu framework. Ai, você teria que desenvolver mais uma camada… mas trabalho.

Exato. E eh ai que comecamos a sentir o poder do Ruby e outras linguagens mais “dinamicas” em relacao ao Java. Vai chegar um ponto em que os recursos de reflection do Java nao vao dar conta (como os finders dinamicos). Claro, sem contar a questao da clareza do codigo.

Eh isso que as vezes o pessoal nao entende. Nao eh questao de “menos linhas” simplesmente - eh a “expressividade” da linguagem, digamos assim. Coisas como essa que estamos discutindo, que envolvem meta-programacao, tornam-se muito mais simples nesse tipo de linguagem. Pra desenvolver infra-estrutura seria uma mao-na-roda contar com recursos como classes abertas e modulos (modulos Ruby especificamente).

Ha uns dias quis criar um componente Table Swing que mantivesse-se sincronizado com uma lista de objetos e vice-versa de forma transparente, sem depender da interferencia do programador da aplicacao. A saida que achei foi utilizar a cglib.

Coisas como AOP causam “frisson” na comunidade Java, mas sao recursos para simplesmente contornar limitacoes da linguagem no campo da meta-programacao. Em linguagens como Ruby, Lisp, Smalltalk, Python, etc, isso nao faria sentido.

Marcio Kuchma

Certo.

saoj:

A não ser que alterássemos o byte code em tempo de execução tipo JDO.
Alguém aqui tem experiencia com isso ?

Também não dá. Em tempo de execução seria até possível, mas quando você tiver programando, como você vai fazer? Vai dar erro de compilação por que o método(get/set) ou o atributo não existe.

Mas há uma luz no fim do túnel, no Java6 o APT pode modificar uma classe, e esse auto-mapeamento poderia ser feito pelo APT. Mas só no Java 6.

Não adianta, Sérgio, por causa do static bingind o compilador vai esperar que a classe chamada tenha o método para compilar sua classe, este método não pode ser criado dinamicamente.

O que dá pra fazer é usar algo como o APT ou um outro pré-processador mas aí eu acho que você está tentando tornar uma linguagem estáatica dinâmica e se for rpa fazer isso é melhor usar Groovy ou JRuby.

Boa. O futuro promete. A estrutura da JVM esta evoluindo pra suportar mais facilmente outras linguagens. Essa eh a saida para essa questao. Eu pessoalmente acho que na linguagem Java nao da pra ter, e nem mesmo da pra querer ter, esse tipo de recurso. As grandes empresas querem eh compatibilidade retroativa, estabilidade nos recursos da linguagem, mao-de-obra em abundancia que entenda a sintaxe (pelo menos) da linguagem.

Entretanto a plataforma Java pode avancar suportando linguagens mais dinamicas. Utilizar a plataforma Java, a tecnologia da JVM e uma linguagem como Ruby ou Python [editado: ou Groovy], seria o melhor dos mundos, dentre as possibilidades viaveis.

Marcio Kuchma

pcalcado:

Não adianta, Sérgio, por causa do static bindind o compilador vai esperar que a classe chamada tenha o método para compilar sua classe, este método não pode ser criado dinamicamente.

O que dá pra fazer é usar algo como o APT ou um outro pré-processador mas aí eu acho que você está tentando tornar uma linguagem estáatica dinâmica e se for rpa fazer isso é melhor usar Groovy ou JRuby.

Concordo plenamente, com execão do JRuby, e não vejo nenhum problema em se utilizar Ruby se for melhor e assim. Java é java, ruby é ruby. E viva as diferenças.

Ah, sim, concordo mas utilizar toda a quantidade de bibliotecas, frameworks e o legado java diretamente tem um apelo muito grande.

E esperem o invokeDynamic para um JRuby/Jython/Groovy muito mais potente.

Eu acredito na visão do Perl 6, mesmo que o próprio Parrot não tenha engrenado. Uma VM multi-linguagem é o caminho, e se a CLR não fosse da MSFT ela teria se beneficiado disso e ultrapassado Java.

Ok. Entendi que não dá.

Então tem que codificar as propriedades no bean mesmo.

Pelo menos acho que se vc usar uma convenção marota, tipo colocar um underscore na frente dos fields que precisam ser persistidos, por reflection vc consegue pegar esses campos e construir as queries on the fly.

É pior (menos automático) do que ActiveRecord, mas tb não é o fim do mundo até porque o eclipse já faz isso automaticamente pra vc: gera set/get.

juzepeleteiro:

De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.

Não é a mesma coisa que o ActiveRecord.

Olá

cglib is a powerful, high performance and quality Code Generation Library, It is used to extend JAVA classes and implements interfaces at runtime. Hibernate Uses cglib to generate proxies for persistent classes.

O projeto é tocado por 4 pessoas e parece meio devagar. A idéia é muito boa. Ele é usado por alguns frameworks famosos como Hibernate, Spring, dynaop e Nanning.

[]s
Luca

Só um detalhe sérgio & cia. Lembrando que ActiveRecord do Rails nada mais é que uma implementação do pattern Active Record, e esse sim, pode ser implementado em Java. Não com a mesma claresa, é claro, mas pode.

marcelomartins:

juzepeleteiro:

De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.

Não é a mesma coisa que o ActiveRecord.

Não precisa. Da pra usar a CGLib que faz proxy sem interface. A oitava maravilha do mundo em Java.

Precisa, se não não compila.

Luca:

Olá

cglib is a powerful, high performance and quality Code Generation Library, It is used to extend JAVA classes and implements interfaces at runtime. Hibernate Uses cglib to generate proxies for persistent classes.

O projeto é tocado por 4 pessoas e parece meio devagar. A idéia é muito boa. Ele é usado por alguns frameworks famosos como Hibernate, Spring, dynaop e Nanning.

[]s
Luca

Existe uma duzia de outros, assim como o Javassist que agora é da JBoss.

[]s
Jose Peleteiro

O ActiveRecord do rails é uma implementação do ActiveRecord pattern, isso acho que sabemos.

Mas o ActiveRecord do rails, é um pouco mais do que uma simples implementação. Tem todos os act_as e validate…

Mas o que estamos discutindo é se dá para ter um ActiveRecord, igual a o do Rails, com acts_as, mapeamento transparente e etc; No java.

juzepeleteiro:

louds:

Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.

Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…

Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença.

Eu também, alias na maioria delas. E as poucas que conheci que tentavam padronizar uma única tecnologia. Acaba falhando ou gastando horrores em casos aonde aquele tecnologia não era a mais indicada e for teimosia usaram a padronizada.

Aí vocês já generalizando de forma que o que eu disse pareça absurdo. Numa empresa grande o suficiente existirão vários departamentos, e cada tecnologia vai depender da necessidade. Se uma equipe presta serviço a um cliente que usa apenas .Net, não tem escolha a não ser usar .Net, a outra poderia usar Java. Mas o que eu quis dizer não foi isso.

Numa equipe onde com uma determinada função é necessário que haja uma direção estabelecida do “para onde ir”, senão vira bagunça. Se cada desenvolvedor trouxer de casa o que bem entende por “melhor” isso dificultará por exemplo a sua substituição futuramente se ele sair da empresa, ou se sair de férias, ou se precisar mudar de projeto. Nunca será possível garantir o que está sendo usado, o que também pode levar a problemas de segurança.

A menos que esteja lidando com uma revolução mundial onde haja realmente um ganho para o negócio em termos práticos, não há problema. Mas apenas por gosto de alguém, para fazer o mais do mesmo, aí é diferente (como é o caso do Ruby).

Numa empresa grande o desenvolvedor não tem controle sobre a infrasestrutura, servidores, etc, para se mudar garantir o correto funcionamento do ambiente para outra plataforma já é trabalho suficiente de “convencimento”. Generalizar a ponto de “use o que der na telha” não bate com o que já vi por aí.

Outra coisa, deve-se levar em consideração a facilidade que as ferramentas propiciam. O “grande” argumento contra o Java parece funcionar apenas se alguém usa o notepad, e expõe 100% das propriedades via get/set (i.e., sem noção de OO), usa o Java 1.4 ou inferior (sim, para efeito de dramatização) e necessariamente se usa EJB 1/2 (o que não é necessário na maioria dos casos).

O ActiveRecord do rails é uma implementação do ActiveRecord pattern, isso acho que sabemos.

Mas o ActiveRecord do rails, é um pouco mais do que uma simples implementação. Tem todos os act_as e validate…

Mas o que estamos discutindo é se dá para ter um ActiveRecord, igual a o do Rails, com acts_as, mapeamento transparente e etc; No java.

A idéia do ActiveRecord é interessante, com o 6 vindo acredito que será mais fácil realmente de implementar.

Agora não é o fim do mundo utilizar as annotations do ejb 3 para persistir. Nada de tão complexo.

Cada plataforma / linguagem tem suas limitações / dificuldades. Claro que a mesma tem de evoluir e é o caso da especificação para o Java 6.

Pessoalmente concodo com o Michael Yuan, seu ponto de vista é bastante coerente.

O aprendizado do Ruby irá beneficiar até a evolução da plataforma e substituir e começar do zero tudo denovo, não sei se é a solução. Lapidar e refinar faz parte de um processo interativo, não tão ágil quanto alguns métodos, risos, mas cíclico você garante qualidade.

Olá

Vejam http://jutopia.tirsen.com/ sobre a diferença de fazer em Java (com iBatis) e em Ruby com ActiveRecord…

Jon Tirsén:

For those of you that doesn’t know what iBatis is: It’s a very simple O/R mapper that allows for complete flexibility when it comes to O/R mapping. It doesn’t make any assumptions about the database at all so can therefor handle virtually any (relational) database schema in existance. This flexibility comes to a cost of course, using iBatis is several times more time-consuming and error prone compared to ActiveRecord.

You should not use iBatis unless you really have to: use ActiveRecord instead. I warn you, do not underestimate how much more work it can be to do manual O/R mapping. Or as Chad Fowler so eloquently put it on Rails Core:

"Jon, I like what you’re doing, but by God I hope I never have to use it." </blockquote>

Vejam também o blog do Martin Fowler: EnterpriseRails

[]s
Luca

pcalcado:

marcelomartins:

juzepeleteiro:

De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.

Não é a mesma coisa que o ActiveRecord.

Não precisa. Da pra usar a CGLib que faz proxy sem interface. A oitava maravilha do mundo em Java.

Precisa, se não não compila.

Eu não to falando o que eu acho. To falando que eu uso o CGLib pra fazer proxy de classes sem criar as interfaces e funciona muito bem. O CGLib é ninja, e alem de me economizar um trabalhão ainda deixou todo o projeto muito mais limpo e claro (adjetivos que podem ser associados ao ActiveRecord também se comparado ao hibernate).

pcalcado:

marcelomartins:

juzepeleteiro:

De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.

Não é a mesma coisa que o ActiveRecord.

Não precisa. Da pra usar a CGLib que faz proxy sem interface. A oitava maravilha do mundo em Java.

Precisa, se não não compila.

Não precisa mesmo. DynAOP faz mixins usando proxy sem que você precise definir interfaces.

Olá

[]s
Luca

Luca:

Olá

[]s
Luca

… exatamente porque o Dynaop utiliza o CGLib. Ultimamente acho que estou excessivamente disléxico. Preciso melhorar isso

Criar proxies dinâmicos para classes é uma coisa. Inserir novos métodos é outra. Como é possível compilar o cliente da classe chamando métodos que só são definidos em runtime? Para usar mixins via AOP, o cliente não precisaria fazer cast para o tipo do mixin (que precisaria conter as definições dos métodos)?

Exato. Não esqueçam: Javatem tipagem estática, mudar isso é possível, mas não é Java! Não obedece à JLS.

Ok tudo se resume em:

“Em Java é impossível chamar um método que não foi codificado hardcoded mesmo.”

Of course, vc pode usar reflection para chamar qualquer método no runtime, inclusive um que foi criado vai modificação de byte code ou algo parecido.

Mas vc não vai querer codificar o seu bean assim:

public class Person {


    public Object get(String property) {

   }


}

Principalmente porque em java tem um monte de coisas que dependem do getter (getUsername, getAge, etc). Expression Language do JSP é uma delas.

Se bem que essa discussão é meio doida, pois se vc não sabe no compile-time quais os campos, então vc não sabe que existe um username, e vc nunca deveria chamar no seu código um getUsername() da vida.

A coisa se resume em: não dá para criar um método no runtime ! Reflection não é um método.

Thiagosc:

juzepeleteiro:

louds:

Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.

Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…

Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença.

Eu também, alias na maioria delas. E as poucas que conheci que tentavam padronizar uma única tecnologia. Acaba falhando ou gastando horrores em casos aonde aquele tecnologia não era a mais indicada e for teimosia usaram a padronizada.

Aí vocês já generalizando de forma que o que eu disse pareça absurdo. Numa empresa grande o suficiente existirão vários departamentos, e cada tecnologia vai depender da necessidade. Se uma equipe presta serviço a um cliente que usa apenas .Net, não tem escolha a não ser usar .Net, a outra poderia usar Java. Mas o que eu quis dizer não foi isso.

Não! Sem essa de que eu estou querendo fazer você parecer um idota que só fala absurdo. Não leia meus textos como se eu estivesse brigando com você para ver quem tem razão. Eu entendo a sua opinião, respeito, só não concordo. E disse que conheço lugares aonde o pessoas dizem: – Aqui só usamos Java (ou o que quer que seja)
E que na minha opinião os caras em muitos projetos, que outra tecnologia seria mais recomendada, gastam mais e não tem tanto sucesso como teriam se adotasem uma tecnologia melhor.

Mas que felizmente, na maioria das empresas que eu conheço, e muitas são empresas enormes (infelizmente não seria ético dizer nomes aqui), não é assim que funciona. No máximo o que acontece é: De preferência para a tecnologia X. Se não fizer tanta diferença use essa.

Thiagosc:

Numa equipe onde com uma determinada função é necessário que haja uma direção estabelecida do “para onde ir”, senão vira bagunça. Se cada desenvolvedor trouxer de casa o que bem entende por “melhor” isso dificultará por exemplo a sua substituição futuramente se ele sair da empresa, ou se sair de férias, ou se precisar mudar de projeto. Nunca será possível garantir o que está sendo usado, o que também pode levar a problemas de segurança.

A menos que esteja lidando com uma revolução mundial onde haja realmente um ganho para o negócio em termos práticos, não há problema. Mas apenas por gosto de alguém, para fazer o mais do mesmo, aí é diferente (como é o caso do Ruby).

Numa empresa grande o desenvolvedor não tem controle sobre a infrasestrutura, servidores, etc, para se mudar garantir o correto funcionamento do ambiente para outra plataforma já é trabalho suficiente de “convencimento”. Generalizar a ponto de “use o que der na telha” não bate com o que já vi por aí.

Sim, no cenário em que você está falando é totalmente verdade. Se o cara não tiver um arquiteto de solução que defina qual a melhor tecnologia e arquitetura para aquele projeto e melhor ele pegar uma e ficar com ela pro resto da vida.
Mas, no cenário que eu estou falando, empresas contratam um arquiteto de solução (normalmente de uma consultoria) que faz um estudo do projeto e chega a uma conclusão, que pode ser aquele projeto é melhor em C, eles vão contratar uma consultoria especializada para desenvolver em C. Não estou falando de ter um time que saiba todas tecnologias. Mas chamar o time que sabe aquele que a deve ser usada.

E nem todos os argumentos para essa decisão são técnicas. Coisas como preço, prazo, mão de obrar no mercado, fornecedores, desejos do cliente entre outras são avaliadas.

Não estou falando de ficar mudando a tecnologia de um projeto e etc, nem que qualquer um vem e muda uma coisa. Mas existe um cara, o arquiteto de solução, que têm esse papel e essa capacidade.

Por exemplo, em uma empresa que conheci os caras estavam fazendo um sistema de simulação matemática em Java, por que java era a tecnologia deles. Quando chegamos lá sugerimos que o mesmo fosse feito com auxilo de bibliotecas matematicas, que são normalmente em C ou Fortran. Ele chamaram varias consultorias com skill para fazer isso, selecionamos uma, e foi desenvolvida em C. E de 10 dias de processamento passou para 1 hora (Isso mesmo). Não que o Java seja uma má tecnologia, apenas não era apropriada para isso.

Agora, imagine um projeto, aonde se vai ter 3-5 usuário e é só entrada de dados. E está toda hora sendo mexido. Eu conheco um monte assim, principalmente quando se trata de sistema de entrada de parametros para um sistema de BI. (preço do dolar, meta da empresa para esse mes, coisas do tipo). Eu pergunto: Para que usar Hibernate, JSF, JSP, Struts, EJB? Nessa caso, com um Ruby da vida se vai muuuuuuito mais rápido e eu diria até melhor.

Concordo com você que as ferramentas ajudam, mas a minha principal critica quando ao get/set é a legibilidade do codigo, e não poder fazer um objeto.atributo++ coisa do tipo. Eu gosto de ler um código e entender tudo que ele faz lendo ele. Ai vem aquele monte de get set que não quer dizer nada… sim, get e set me irrita.

Cara, não me leve a mal, eu acho Java do caramba. Mas tem seus pontos fracos (assim como fortes) e adimitir isso é muito bom para qualquer profissional.

pcalcado:

AllMighty:

Como é possível compilar o cliente da classe chamando métodos que só são definidos em runtime?

Exato. Não esqueçam: Javatem tipagem estática, mudar isso é possível, mas não é Java! Não obedece à JLS.

Obvio, é impóssivel chamar um método que não está definido na classe. Isso é fato. Java não faz isso.

Quando eu disse que é possivel fazer proxy sem interfaces com o CGLib estav comparando com o sistema de proxy nativo do Java, que usa Interfaces. E o CGLib faz proxy em runtime, ele cria uma nova classe e devolve ela. Tudo em tempo de execução. Mas só os métodos que estão definidos na classe original é que podem ser chamados.

Mas ai tem o seguinte. A gente ta comparando linguagens dinamicas com a tipagem estatica do Java. E isso não pode ser. São coisas diferentes. Comparamos então com o groovy, que pode ser chamado métodos que não existem e todos caem em um método padrão.

Pois é, e então isso volta ao ponto: não dá pra implementar AR Rails-Like em Java.

Concordo em parte. Parece que o seu ponto vista é exclusivamente de consultor, onde pegam uma pessoa do mercado, ela faz o sistema, e tchau. Numa empresa que conta com uma equipe fixa de funcionários via CLT ou via PJ, mas que sejam mais ou menos fixos, não é tão simples pois a rotatividade é razoável mas não a ponto de trocar o arquiteto e todos os desenvolvedores a cada projeto.

Além do mais se a empresa é uma empresa de TI ela provavelmente terá produtos que deseja oferecer a seus clientes. Simplesmente abandonar uma plataforma com a qual está compremotida até o pescoço e escrever tudo do zero é inviável na maioria dos casos. Apenas se houver demanda forte do mercado por outra (tipo, seus possíveis clientes pedindo), e já vi gente migrando para o Java por causa disso.

O fato de Java não ser bom para uma coisa não justifica a outra. Nenhuma linguagem é boa para tudo, mas aí é necessário mais do que simples contagem de keystrokes e cenários fantasiosos.

Um exemplo de exagero é o vídeo de propaganda do Rails, que mais parece um Wizard do Word onde o usuário entra com alguns dados e pronto. O problema é quando se sai dos “trilhos”, o fácil já não é tão fácil.

Se pensarmos pela mentalidade de muitos que usam Ruby amanhã todos largaríamos o Java para usar VB. Quer coisa mais fácil para fazer aplicações comerciais do que VB? Mas isso torna o VB a melhor linguagem do planeta e um Java-killer? E porque que tem gente que ainda prefere desenvolver usando Java com Swing ou SWT? Não seria melhor usar só VB pois é muito mais rápido e mais fácil?

juzepeleteiro:

Cara, não me leve a mal, eu acho Java do caramba. Mas tem seus pontos fracos (assim como fortes) e adimitir isso é muito bom para qualquer profissional.

Apenas acho que as vantagens de determinadas linguagens são exageradas e os testemunhos beiram o absurdo. Trabalho com outras linguagens script e perto delas o Java parece o sinônimo de “ordem” e elas o de “caos”.

O problema que eu tenho com Ruby é o mesmo que eu tenho com Spring, simplesmente “é tudo de bom”. Você já viu algo sem falhas?

Você olha e pensa “Mas em que situações eu usaria isso?”, depois procura algum depoimento de pessoas experientes na tecnologia à procura de situações práticas e nada. Lê sites e tutoriais, acha tudo muito normal, com algumas exceções horríveis aqui e ali e outras legalzinhas aqui e ali, mas não o suficiente para entender todo o “cheerleading”. Procura perspectivas futuras e encontra filosofias…

Acho que falta um pouco de pé no chão.

Tua opinião tem fundamentos, mas tb não precisa gastar tanto keystroke assim. Tá parecendo:

BufferedReader br = mew BifferedReader(new InputStreamReader(socket.getInput()));

Não sei se você já pegou algum projeto em VB, mas eu já. Estava em um até 2 meses atrás. Dói.

Taí uma coisa que deve-se pensar muitooo bem antes de começar a desenvolver algo: Swing ou SWT. Não que eu tenha trabalhado já com alguma delas, mas até onde sei e já ouvi relatos, .Net para desktop, está anos (anooos) à frente.

Olá

Como é sabido aqui no GUJ, eu não tenho a menor idéia para que serve um programa desktop que funcione isolado. Até costumo dar os exemplos daqueles programas do milênio passado tipo Office que não permite que o chefe em Ipanema trabalhe na mesma planilha que o funcionário na Tristeza.

Me mate uma curiosidade. Acho que a resposta deve ser sim mas em todo caso pergunto: Com .NET é fácil fazer sistemas que enviem e recebam mensagens http/https? Com Java + HTTPClient é tranqüilo.

[]s
Luca

Sim, é sim. WebService com .NET por exemplo é a coisa mais linda do mundo. Melhor até do que o XFire, nos usamos sempre o .NET como inpiração no XFire.

Um abraço,
Jose Peleteiro

Lembrei agora, tempinho atrás saiu um artiguinho sobre ActiveRecord no IBM-DeveloperWorks.

http://www-128.ibm.com/developerworks/java/library/j-cb03076/

Ah, sim, e é escrito pelo Bruce Tate.

Luca:

Me mate uma curiosidade. Acho que a resposta deve ser sim mas em todo caso pergunto: Com .NET é fácil fazer sistemas que enviem e recebam mensagens http/https? Com Java + HTTPClient é tranqüilo.

[]s
Luca

Luca, não programo nadinha em .Net, mas na empresa tem bastante gente nele. E já ouvi muita melação na parte de criar webservices por exemplo com .Net, que chega a ser estúpido de tão simples. Mas como ainda não vi na prática não posso te afirmar.

Olá

Diego, falo de programas trocando mensagens HTTP/HTTPS mesmo usando URLConnection powered by HTTPClient porque este é o ambiente que eu vivo desde 2001. Alguns dos sistemas desktop que eu trabalhei até trocavam web services mas eram de servidor para servidor nas camadas de servidor.

[]s
Luca

plentz:

Luca:

Me mate uma curiosidade. Acho que a resposta deve ser sim mas em todo caso pergunto: Com .NET é fácil fazer sistemas que enviem e recebam mensagens http/https? Com Java + HTTPClient é tranqüilo.

[]s
Luca

Luca, não programo nadinha em .Net, mas na empresa tem bastante gente nele. E já ouvi muita melação na parte de criar webservices por exemplo com .Net, que chega a ser estúpido de tão simples. Mas como ainda não vi na prática não posso te afirmar.

[WebMethod] public string HelloWorld() { return "Hello World"; }

Qualquer semelhança com

@WebMethod public String helloWorld() { return "Hello World"; }

Não é mera coincidencia. Foi tudo inspirado no .NET

Java já esta bem perto, mas ainda não chegou lá principalmente por que você têm que configurar um servidor de WebService (pode ser o interno do XFire por exemplo, que utiliza o Jetty), e no caso do .NET é só jogar no IIS. Mas com os novos servidores JEE 5, não sei se ainda é necessário.

Thiagosc:

juzepeleteiro:

Mas, no cenário que eu estou falando, empresas contratam um arquiteto de solução (normalmente de uma consultoria) que faz um estudo do projeto e chega a uma conclusão, que pode ser aquele projeto é melhor em C, eles vão contratar uma consultoria especializada para desenvolver em C. Não estou falando de ter um time que saiba todas tecnologias. Mas chamar o time que sabe aquele que a deve ser usada.

E nem todos os argumentos para essa decisão são técnicas. Coisas como preço, prazo, mão de obrar no mercado, fornecedores, desejos do cliente entre outras são avaliadas.

Não estou falando de ficar mudando a tecnologia de um projeto e etc, nem que qualquer um vem e muda uma coisa. Mas existe um cara, o arquiteto de solução, que têm esse papel e essa capacidade.

Concordo em parte. Parece que o seu ponto vista é exclusivamente de consultor, onde pegam uma pessoa do mercado, ela faz o sistema, e tchau. Numa empresa que conta com uma equipe fixa de funcionários via CLT ou via PJ, mas que sejam mais ou menos fixos, não é tão simples pois a rotatividade é razoável mas não a ponto de trocar o arquiteto e todos os desenvolvedores a cada projeto.

Além do mais se a empresa é uma empresa de TI ela provavelmente terá produtos que deseja oferecer a seus clientes. Simplesmente abandonar uma plataforma com a qual está compremotida até o pescoço e escrever tudo do zero é inviável na maioria dos casos. Apenas se houver demanda forte do mercado por outra (tipo, seus possíveis clientes pedindo), e já vi gente migrando para o Java por causa disso.

Sim, se for uma empresa de TI e tiver condições de ter somente uma equipe. E melhor se manter em uma tecnologia, mas sempre procurando se expecializar nela. Eu acho muito triste uma empresa de TI que não investe na melhoria continua dos seus profissionais e na modernização das técnicas de desenvolvimento. No final no final isso significa aumento da qualidade e desempenho. Uma empresa de TI que ainda utilize Struts pôr exemplo está perdendo dinheiro. A não ser que a estratégia dela seja contratar mão de obra do mercado barata e sacrificar a qualidade do desenvolvimento. Mesmo em uma empresa de TI, a função de arquiteto de solução qualificado é muito importante. E uns dos pontos que ele vai analizar na hora de escolher a arquitetura (linguagem, framework, metodologia, design guidelines) e a mão de obra disponivel.

Uma empresa que não é de TI, não deve se meter com TI, a não ser que ela estruture um departamento de TI, cujo o negocio seja TI. Inclusive cobrando aos outros departamentos pelo desenvolvimento. (senão todo mundo que tudo, quando ninguem mete a mão no bolso).

O fato de Java não ser bom para uma coisa não justifica a outra. Nenhuma linguagem é boa para tudo, mas aí é necessário mais do que simples contagem de keystrokes e cenários fantasiosos.

Um exemplo de exagero é o vídeo de propaganda do Rails, que mais parece um Wizard do Word onde o usuário entra com alguns dados e pronto. O problema é quando se sai dos “trilhos”, o fácil já não é tão fácil.

Se pensarmos pela mentalidade de muitos que usam Ruby amanhã todos largaríamos o Java para usar VB. Quer coisa mais fácil para fazer aplicações comerciais do que VB? Mas isso torna o VB a melhor linguagem do planeta e um Java-killer? E porque que tem gente que ainda prefere desenvolver usando Java com Swing ou SWT? Não seria melhor usar só VB pois é muito mais rápido e mais fácil?

Você tá pré-julgando, assim como têm radicais em Ruby têm radicais em Java, ou você nunca vi um apaixonado por Java falar que java era a coisa mais perfeita do mundo, principalmente em briginhas de Java x .NET? Nem por isso Java é linguagem ruim. Assim é com o Ruby, têm gente falando que Ruby é a solução para a paz mundial, têm gente tentando fazer de Ruby a solução para a paz mundial e têm gente simplemente utilizando o melhor disso tudo.

Os que fazem barulhos sempre são uma minoria, mas que gritam bem alto.

No demo do Rails, o cara quis mostrar como é fácil fazer uma coisa básica e um marketing também. Você nunca viu uma demostração do Sun Creator? Parece também que desenvolver uma aplicação completa leva agora 5 minutos. Se sua aplicação for só um mapa do google.
E marketing, acontece lá, e acontece aqui também. Mas nem por isso deixei de usar Java ou Ruby.

[joke=on]O GUJ deveria ter um ranking dos tópicos mais longos :D[/joke]

Mais ou menos, e dependendo de como tu for analisar, o .Net está apenas alguns meses afrente.

E se a gente for fazer essa mesma comparação depois que o Mustang for lançado, ai não vai precisar muito esforço pra por o Java net frente.

Mais ou menos, e dependendo de como tu for analisar, o .Net está apenas alguns meses afrente.

E se a gente for fazer essa mesma comparação depois que o Mustang for lançado, ai não vai precisar muito esforço pra por o Java net frente.

Sim, o Java esta evoluindo e o .NET também, esse tipo de comparação que você fez deveria ser feito com o próximo .NET com o próximo Java.

No próximo .NET, ate aonde eu sei, virá com uma nova ideia de desktops, aonde o Office 2007 é o primeiro dessa leva, que parece ser bem legal.

O Java pelo o que eu sei também vai vir com bastante coisa, mas honestamente eu ainda não gosto de Java para desktop.

Para mim, coisa comop VM como serviço (compartilhada) e integração com o sistema operacional (coisa que parece o próximo java vai ter) são ensenciais.

Olá

De http://www.guj.com.br/posts/list/75/36529.java#194394

José Peleteiro:

saoj:

Entendi. Teria que criar os sets/gets dinamicamente, e isso não dá em Java, certo ?

Certo.

saoj:

A não ser que alterássemos o byte code em tempo de execução tipo JDO.
Alguém aqui tem experiencia com isso ?

Também não dá. Em tempo de execução seria até possível, mas quando você tiver programando, como você vai fazer? Vai dar erro de compilação por que o método(get/set) ou o atributo não existe.

Mas há uma luz no fim do túnel, no Java6 o APT pode modificar uma classe, e esse auto-mapeamento poderia ser feito pelo APT. Mas só no Java 6.

De http://www.guj.com.br/posts/list/75/36529.java#194399

Phillip Calcado:

Não adianta, Sérgio, por causa do static bingind o compilador vai esperar que a classe chamada tenha o método para compilar sua classe, este método não pode ser criado dinamicamente.

O que dá pra fazer é usar algo como o APT ou um outro pré-processador mas aí eu acho que você está tentando tornar uma linguagem estáatica dinâmica e se for rpa fazer isso é melhor usar Groovy ou JRuby.

Tchan, tchan, tchan…

[color=darkblue]Seus problemas vão acabar …[/color]

Vejam:
Java 6 compilará fonte dentro de uma aplicação pronta

De passagem vejam também:
Java 6 permitirá misturar scripts com código Java

[]s
Luca

Eu acho que com a possibilidade de Java 6 se tornar mais fácil e dinâmica, com recursos de compatibilidade de self-compiler e cross-script, então ela permitirá que surjam frameworks e métodos diferenciais de hoje em dia, quem sabe teremos um framework mais poderoso e mais fácil que o RoR?

Eu como desenvolvedor .net e java posso responder a pergunta sobre “.net pra desktop”

Sobre o .net ser melhor que java pra desktop:
Pode ter certeza que depende muito do programador, SIM, depende.
Fazendo uma comparação entre java e .net pra windows:
SIM, .net ganha do swing MAS, por incrível que pareça amigos, SWT vs VS2003, o SWT ganha! SIM, o swt tem componentes que o VS2003 NÃO TEM! Sério mesmo. Eu tenho preferência pelo SWT, mas como não sou O programador quente em java, mesmo eu utilizando o SWT, no VS é bem mais rápido, no VS você cria, compila e gg. É só executar o .exe e tá rodando, mesmo se estiver precisando de bibliotecas de terceiros. Já no SWT, como meu conhecimento em cima do ant é baixo a unica coisa que eu tenho que fazer é mover o projeto do eclipse pro netbeans e dar um build lá.

SWT é tão rápido quanto o VS2003

Mas o VS2005 bate forte o SWT, tem muitas coisas novas nele e, o VS2005 acabou tornando o c# um poderoso “java wanna be” pra desktop (windows). Há integração com os produtos da microsoft e já tem até hibernate pra ele (já faz um tempinho que o .net ganhou o n-hibernate e nesse VS2005 já tem generics IGUALZINHO do java).

Concluindo: vai de programador pra programador, c# não tem muita diferença pro java, mas eu particularmente prefiro o java, eu não conseguir até agora fazer MVC no .net nem em desktop muito menos na web, nem em SWT ainda não consegui fazer MVC, então fica elas por elas lol). Mas .net eu respeito, é uma tecnologia digna de ser considerável párea pro java (por favor, não quero dizer que JEE > .net, porque .net distribuído só o asp.net que é legalzinho, o resto é LIXOOOOO), .net pra leitura de XML MATA A PAU! É ANIMAL! Rápido e simples de fazer, pra criar webservices SIM, é muito rápido e fácil, pra manipular arquivos é simples, tu faz um File.Delete( “Caminho do arquivo” ); e pronto, deleta ele. Mas .net = windows, distribuição = IIS, ele não tem nenhuma chance em outras plataformas. Por isso java ganha fácil.

Comparar java com .net em ambiente windows é complicado. É a mesma coisa que fazer um jogo de futebol sendo o .net um time que joga em casa. O java sim pode ganhar, mas nem sempre.

Mas sobre o java vs .net pra desktop
Aqui vai umas screenshots de um programinha de gerência de redes que eu criei, adivinhem em que?

Antes de falar mal de java pra desktop, favor olhar essas imagens

http://img526.imageshack.us/img526/6292/networkscan11dq.png
http://img368.imageshack.us/img368/3927/printermib17jp.png
http://img526.imageshack.us/img526/739/printermib28su.png
http://img263.imageshack.us/img263/2363/chartwizard9vz.png
http://img263.imageshack.us/img263/7126/main6bq.png
http://img526.imageshack.us/img526/6773/tables1ke.png

putz agora que eu ví que escreví viZualizar

Olá

Leozin, algums dúvidas totalmente fora do tópico principal desta pasta:

1. Este programa que parece muito bom, com belas imagnes foi feito com SWT?

2. Em .NET você usa C# ou VB?

3. Os programas que você chama de desktop rodam confinados em rede local ou trocam mensagens HTTP (não obrigatoriamente web services) pela Internet?

4. O SWT é melhor do que o Swing em quais quesitos?
   a) Rapidez de desenvolvimento;
   b) Melhor desempenho
   c) Maior número de facilidades e componentes gráficos

[]s
Luca

Sim, totalmente em SWT, somente os próprios gráficos (que são JPanels, por causa do JFreeChart) e os relatórios (por causa do JasperReports)

Somente um projeto que eu tenho que lidar com vb.net, o restante dos projetos que eu lido são em C#

Luca:

3. Os programas que você chama de desktop rodam confinados em rede local ou trocam mensagens HTTP (não obrigatoriamente web services) pela Internet?

Luca:

4. O SWT é melhor do que o Swing em quais quesitos?
a) Rapidez de desenvolvimento;

Luca:

b) Melhor desempenho

Luca:

c) Maior número de facilidades e componentes gráficos

Espero ter ajudado

O problema que as pessoas acham do Java Desktop é querer que ele funcione da mesma forma que VB e Delphi para os mesmos afins.

Porém por Java ser OO e a filosofia da linguagem como um todo ser diferente, o Java Desktop (swing, swt, awt) trabalha de forma diferente dos tradicionais RADs da indústria.

Java Desktop é poderossísimo, faz coisas impressionantes, mas isso tudo tem seu preço, é o custo do aprendizado que não é difícil, e sim um pouco trabalhoso. E a produtividade que em muitos casos é mais baixa.

Pois é, Luca, mas da mesma forma não seria java. Java é tipada estaticamente, se você misturar scrits não é mais Java.

Para compilar:

class A{

 private B b;

 { b.metodoDinamico(); }
}

Eu preciso que exista uma classe B contendo um método metodoDinamico e isso não se resolve com compilação dinâmica.

Acho que Java tem suas características e deve-se trabalhar dentro delas. As linguagens de script de JVM hoje já são uma ótima alternativa para lugares onde Java não é eficiente (pra quase tudo Java é eficaz, eficiência é outra história).

É usar a linguagem certa para o trabalho certo, já fazemos isso com SQL, HQL, XHTML…

E falando de Java e Ruby…

Interviewing the JRuby Developers