1. One-slide technology: it's so simple that I can explain basic JSF with one slide.
2. Easy to extend: components, listeners, render kit, Events, Controller, etc.
3. Real-world adoption: JBoss, Exadel, Oracle, IBM, ...
4. Architecture model: you can choose between more than 100 different architecture.
5. Open-mind community: using JSF you are going to meet very interesting people.
6. We are using JSF the last 5 years and we found very good market for JSF in Brazil
7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard!
8. Many professionals now available
9. It's a standard. It's JCP. Before complain, report and help!
10. Ed Burns, spec leader, is an old Globalcode community friend!
EXTRA: My wife is specialist in JSF. She's my F1 for JSF :)
Nice job JSF community!
-Vinicius Senger
2. Easy to extend: components, listeners, render kit, Events, Controller, etc.
3. Real-world adoption: JBoss, Exadel, Oracle, IBM, ...
4. Architecture model: you can choose between more than 100 different architecture.
5. Open-mind community: using JSF you are going to meet very interesting people.
6. We are using JSF the last 5 years and we found very good market for JSF in Brazil
7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard!
8. Many professionals now available
9. It's a standard. It's JCP. Before complain, report and help!
10. Ed Burns, spec leader, is an old Globalcode community friend!
EXTRA: My wife is specialist in JSF. She's my F1 for JSF :)
Nice job JSF community!
-Vinicius Senger
Comentários
- vc consegue explicar jsf em 1 slide?
- serio mesmo que ele é facil de estender e tal?
- vc acha que o progresso mega lento da spec realmente é "working hard"?
- e vc realmente acredita que ser uma spec oficial é melhor que outras coisas?
-Sim consigo explicar o conceito de managed bean + view em um slide. Obviamente que vc é inteligente o suficiente para entender o contexto.
-Sim é fácil de estender. Se vc acha difícil deve ter sérias dificuldades com outras coisas no Java.
- Acompanhei a spec desde seu primeiro release pessoalmente. Se vc tivesse idéia do que é unir Gavin King, Ed Burns, Kito e mais meio mundo da Web, entenderia melhor o valor do JCP.
- Sim acho que é bem melhor usar algo da spec. Simplesmente pelo fato que faço parte dela e posso colaborar com ela.
A propósito, para que mudar o JSF duas vezes por ano se as empresas só sobem a versao do JAva EE a cada quatro anos?
Quer algo que mude rápido, acompanhe a previsão do tempo.
-Vinicius
Bacana o post Vinicius.
Peço para quem for contra o JSF comentara tecnologia que usa.
Obrigado,
Vinicius
A propósito, será que chove hoje Robson? Haha!
Ótimo post primeira vez que passo por aqui, vou dar uma olhada nos outros artigos!
A Web é muito complicada... Muita gente trabalhando com diferentes tecnologias e existem vários que realmente não gostam de JSF, mas nunca apresentam uma tecnologia concorrente que tenha todas as caracteristcas boas do JSF e algo a mais.
Da forma como foi estruturado o JSF, desvinculando implementação de interface, com várias implementações, altos progressos com AJAX, união de várias empresas e nomes, alta adoção no IDE's faz dele um projeto de muito sucesso na minha opinião.
Agora, o conceito de velocidade de mudança é diferente para cada um, em sua necessidade. Eu poderia passar o resto da minha vida vendendo aplicativos com J2EE usando Struts aqui em Ubatuba. Já no Vale do Silício não.
Alguns precisam programar para surfar, outros para viajar o mundo, outros para comprar uma casa. Os que programam por programar, fica apertando F5 esperando um novo release. Pra ficar tudo mais fácil...
Eu sinto que se ficar mais fácil do que está, eu vou começar a ficar mais burro. RS.
Viajens a parte, desculpem minha opiniões pessoais. Robson e Ricardo venham em casa que faço uma pizza para assarmos junto com os frameworks web tomando uma gelada.
[]s
Vinicius
o amigo robson ai, poderia ter sido ao menos mais educado...
Concordo com as suas opiniões, e quanto a pizza eu levo as geladas! =)
Um abraço!
Eu uso atualmente Grails com ZK, to gostando muito. (Não significa que o que eu uso seja padrão e possível de ser trocado, coisa que claramente não é).
- RichFaces, IceFaces, PrimeFaces, Tomahawk, Trinidad entre outros.
Eu curto a idéia de desenvolvimento baseado em componentes visuais na web, com uma arquitetura bem bolada no back-end, principalmente em aplicações corporativas.
[]'s
Eder
A única coisa q a Sun prometeu e não pegou foi poder ter uma paleta de arrastar, soltar e posicionar os componentes como num Visual Studio ou num editor de Swing do NetBeans. Eles implementaram no NetBeans mas os componentes eram proprietários. Quem sabe não podem resgatar isso? Iríamos ganhar ainda mais produtividade e a arquitetura permite.
Bons códigos,
Jeff
Fazendo esta analogia o problema somente seria solucionado se existisse algo como aconteceu com os drivers Microsoft: haveria um processo de certificação da biblioteca de componentes e se o desenvolvedor utilizar bibliotecas sem o certificado, perde esta garantia.
Enfim, o que não se resolve em compile-time, tem que ser resolvido com altruísmo (ai, essa denunciou que estou bebendo vinho ahahaha).
[]s
Vinicius
E como fica na hora de escolher entre as muitas implementações? Você põe a mão no fogo em qual? Citando o Eder: RichFaces, IceFaces, PrimeFaces, Tomahawk, Trinidad entre outros. É nesse momento que a casa cai numa discussão pró e contra JSF.
O Core Java não é uma especificação que ainda se possa contar com tendências, até parece que nada mudou e features não são mudadas também, me parece que o Vinicius Senger parou no tempo ou ele entende especificação quando o JCP fazendo sentindo em versões e publicações das chamadas JSR.
"Felipe, excelente comentário. De fato a compatibilidade entre produtores de componentes foi um assunto muito em pauta no JSF 2. O problema disso é muito semelhante ao de device drivers para sistema operacional"
Isso é a pior análise pra se pensar em problemas, buscar fatores de implementação em vias sobre especificação de fornecedores, isso não se baseia em nada sobre outras especializações já citadas acima, algo como eu segui-se uma tecnologia a risca como um norte de verdade.
A arquitetura hoje é levada por linguagens que atendem plataformas dinamicas e sejam mais modulares, em vista disso a WEB é sim e a maior nuvem se não a maior CLOUD que vai ter fusões pra muitas midias, hipermidias e URIs de fornecedores de serviços.
Vc tem razão, escolher mais de uma implementação "terceira" no mesmo projeto é complicado, dependendo da situação tem que ralar bastante p/ fazer funcionar.
Agora aproveitando o gancho do Vinicius, melhorar isso foi uma preocupação da spec 314.
De certa forma demonstra a maturidade da tecnologia e a importancia da comunidade e suites de componentes, os caras "baixaram a guarda" pra problemas do dia-a-dia (que a spec ñ resolve).
[]'s
Eder
Não sei se concordo... acho que precisa de mais de um slide pra ensinar JSF pra alguém
> 2. Easy to extend: components, listeners, render kit, Events, Controller, etc.
Eu trocaria "Easy" por "It's possible". Definitivamente não é Easy.
> 4. Architecture model: you can choose between more than 100 different architecture.
Em quais outros frameworks web você não consegue ter diferentes tipos de arquitetura?
> 5. Open-mind community: using JSF you are going to meet very interesting people.
?
> 7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard!
Demorou vários anos pra arrumarem defeitos bem básicos... não acho o progresso do JSF algo notável
De preferência sem o anonimato...
Tem projetos que qq porcaria de Web resolve. Mas projetos grandes, em grandes servidores, para grandes equipes, com grande contratos o padrão faz total diferença!
Sim, isso seria um requisito não funcional e, normalmente, imposto por quem paga a conta. Não é, tecnicamente, um diferencial do JSF... seria um diferencial, humm, "executivo" hehehe
Eu ainda não trabalhei em projetos tão grandes, por isso tenho uma certa liberdade de escolher quais tecnologias usar. Eu já me peguei pensando se iria gostar de trabalhar num projeto grande onde eu seria obrigado a usar várias tecnologias sem motivos técnicos só porque a empresa quer.
O ideal seria que as várias aplicações falassem entre si independente da implementação assim cada projeto seria mais livre para escolher o que é melhor pra ele, todo sabemos que não existe bala de prata.
Os comentários excedem minha inteligência... Minha opinião esta ai e esqueci de citar um motivo muito muito muito especial pelo qual eu gosto de JSF: eu ganhei muito dinheiro com ele e vou continuar ganhando!!!! JSF vende que é uma beleza. AHAHAHAHAHAH.
Resposta:
Estamos discutindo a utilidade de uma tecnologia, ao motivo especial isso é mera opinião sua.
Vinicius Senger disse...
E até agora ninguém falou o que usa. Por favor me respondam: o que é melhor que JSF e porque?
Resposta:
Spring-MVC é melhor que JSF, é mais dinâmico tem melhores especializações e não vem com aquela cara de swingão que traz o JSF.
O ideal seria que as várias aplicações falassem entre si independente da implementação assim cada projeto seria mais livre para escolher o que é melhor pra ele, todo sabemos que não existe bala de prata.
Não existe a bala de prata, mas existe o bom design e a visão ao que hoje se atende para plataformas e frameworks funcionais e não funcionais.
O que acontece é a falta de pesquisa e investimento ou mesmo querer estar em forúm somente por uma força de marketing e vendas.
Temos tecnologias poderosas ai para o back-end e outras que tem sua responsabilidade de atender camadas e interfaces.
Mas infelizmente o que esta atrapalhando que todos evoluam é um efeito publicitário esmagador e rotulado que vem embalado "Tipo dessas opiniões chulas, eu ganhei muito dinheiro com JSF", então vamos começar ter novos horizontes e compreender o que nos espera, e na certa vem ai muita convergência e interoperabilidade, desafios novos com Restful entre novas arquitetura.
O legado existe e deve ser planejado o seu recurso para o novo e as novas tendencias da JVM.
Vem a questão acima, ao anônimo meus pensamentos a minha pessoa a melhor integridade.
Comparar um framework action-based com um framework component-based faz tanto sentido quanto propaganda política.
Spring MVC pode ter tais vantagens sobre Struts, Webwork, etc. A proposta e forma de implementação do JSF é completamente diferente.
Sem contar que o desenvolvimento da camada view com Spring MVC é delegada para outro framework geralmente, diferente da utilização dos componentes do próprio JSF.
Gostaria de saber também o que o pessoal tem utilizado no lugar de JSF.
Spring-MVC não é um framework baseado em componentes como o JSF. E para te poupar o trabalho de entender toda a conversa eu não uso JSF, nem defendo. Uso Grails no back-end e ZK como framework de componentes.
Me peguntaram o que era melhor, e realmente não dá pra comparar mesmo Spring-MVC com o JSF, e falando em delegação para outros frameworks até com Freemarker, veja quantas soluções temos ai, mas ai vem o Papai Noel dizer que a sacola dele tá minando dinheiro... ;-)
Felipe, gostei muito dos seus comentários. Principalmente a classificação como "requisito executivo" foi muito inteligente.
Impressão minha ou as opiniões anonimas tem uma qualidade muito inferior das opiniões assinadas?
Risos.
Anonimos também são bem-vindos na minha casa para comer pizza e tomar cerveja. Ai podemos discutir futebol.
Uso Grails no back-end e ZK como framework de componentes."Legal que você tem uma visão, diferenciada"
Quanto a pergunta do Vinicius Senger Por favor me respondam: o que é melhor que JSF e porque?
Ele foi infeliz, ainda o Rafael tentou passar um cimento branco de mau qualidade em ter que buscar referencias ao JSF sobre Spring-MVC não dá né basta mesmo ver como as ramificações ao Spring se extendem e não dependem do Core J2EE, tem gente querendo vender elefante branco. ;-)
Impressão minha ou as opiniões anonimas tem uma qualidade muito inferior das opiniões assinadas?
Risos.
A minha impressão é quem advoga de opiniões a seu favor, faz isso com pessíma qualidade de observação.
Grails no back-end ? é furada tá mais pra uma engine dependente do Core Java a ser uma real full-stack.
Pior falar de implementação JSF e argumentar o que é diferente,isso é não ter senso de profundidade ao que cabe as responsabilidades e aspectos da tecnologias, isso é muito vago.
Observação, acho que estudar conceitos de User Experiencie vai dar melhor referência no que cabe trabalhar com Model View Controller.
É senger essa Pizzaria vai longe ;-)
A melhor parte do Grails pra mim, ser completamente integrado ao java e de forma transparente. Pude re-usar vários códigos que eu possuia ao invés de reinventar a roda.
Ele te fornece o fullstack ao juntar tecnologias e não ao fazer tudo do zero. Essa informação não fica escondida em lugar nenhum e é um trunfo dele.
http://bit.ly/bSvBAb ;-) , senão tiver o JSF não tem importância é só indo aprendendo coisas novas e interessantes !!!
WHAT'S INSIDE
* Build a Java web app with the AppFuse framework and Maven
* Build a rich client with Flex 4
* Connecting to Webservices services
* Connecting to Spring, EJB3, POJOs, and others
* Flex Messaging using JMS
* Securing Flex
* Create custom Flex controls with Degrafa
* Desktop 2.0 with Adobe AIR
* Flex on Grails
* IDE Integration
Ele te fornece o fullstack ao juntar tecnologias e não ao fazer tudo do zero. Essa informação não fica escondida em lugar nenhum e é um trunfo dele.
Vejamos
Você não atingi um Hyper-Treading como Scala pois groovy é produtivo dentro de uma plataforma, é tem mais escalabilidade é a palavra chave."Scala faz coisas simples serem fáceis e coisas difíceis serem possíveis".
Seu back-end precisa ser revisto. ;-)
A propósito, porque não escreve um artigo de introdução a scala?
O que seria hyper-treading como scala? Não entendi.
[]s
Vinicius
Particularmente eu não gosto do JSF porque não gosto do modelo baseado em componentes para a Web. Acho que o modelo proposto pelo HTML5 com JS e CSS é o que deve ser usado para a WEB. Buscar os padrões mais usados (do W3C)é mais legal. Até porque isso te permite uma diversidade maior na escolha de tecnologias de integração.
Também não gosto do JSF porque ele dificulta o REST. (Ainda não suporta requisições GET com parâmetros ou to viajando?)
Mas respeito a opinião de quem gosta de desenvolvimento baseado em componentes e acho que dentro deste modelo o JSF é o melhor. Também concordo que grandes corporações preferem coisas assinadas. Mas eu não gosto de grandes corporações.
Para o Felipe Cypriano, Grails é Front-End e não backend. A camada MVC inteira é front-end por sinal. Isso não quer dizer que não dê pra usar Groovy no backend como o anonimo disse. Se dá pra fazer em Java, dá pra fazer com Groovy.
Scala é uma das linguages que eu mais gosto, porém ela nào simplifica as coisas, pelo contrário. Complica coisas simples. Quem já tentou converter um List que retorna de um driver JDBC para um List em Scala sabe do que eu to falando. Mas é uma boa escolha para algumas situações.
O que eu uso? Eu uso de tudo. De verdade.
Ruby, Python, Java, Scala, Groovy, Ioke, etc...
Tenho mais projetos em Java e Rails.
Pra terminar, sou a favor da escolha certa para a necessidade certa. Ponderar porque e quando usar uma tecnologia é bom. Ser xiita e defender ou criticar até a morte é errado.
Sim já tive esse pensamento, em escrever um artigo mas existe assuntos que não são visto pelo marketing então não seriam publicado.
O Termo certo é Hyper-Threanding "O que sugere melhor conceito para programação para Cloud Computing".
Na Edição 75 - Java Magazine - Scala é o tema principal.
Em nota tem uma informação sobre:Transparência referencial, pagina 37.
A Revista Java Magazine desta Edição 77 não falou sobre Closure isso foi uma falha ou algo proposital não sei, no Java 7 essa funcionalidade não fora suportava, mas qual a vantagem disso em usar ou não talvez se pergunte: Já lhe respondo a vantagem e de performance e codigo limpo.
Interessante que existe até um site que aborda vários assuntos sobre Scala é o http://javalivros.ning.com ,lá tem vários artigos e informações.
Um video que vi recentemente é o David Pollak On Lift Framework and Scala :
É Bem interessante !!!
http://www.infoq.com/interviews/Lift-Scala-David-Pollak
Mas um cara bom pra conversar e o Jonas Bonér
segue twitter @jboner
http://www.infoq.com/presentations/Scala-Jonas-Boner
No meu caso eu uso o Grails como backend, pois os códigos de serviço e tudo mais são feitos em groovy e usam as configurações do grails (spring por baixo) para ligar o frontend (ZK, não uso GSP nesse projeto) com os services (groovy / grails). Basicamente.
Estou para ler, assim que arrumar tempo, sobre Clojure. Quero entender melhor sobre programação funcional e não quis aprender em Scala porque ela não é só funcional. Depois que eu entender de programação funcional pura eu vejo o Scala.
Entender várias linguagens é ótimo para todos, o seu código ficar melhor em todas elas. Ruim é a pessoa agarrar em uma só e não soltar nunca mais.
Ruim é a pessoa agarrar em uma só e não soltar nunca mais.
Eu estou com você nessa idéia também, por isso que temos que procurar trabalhar com linguagens que sejam Cross-Browser e Cross-VM, pois os caminhos são contextos que se integrem e altas camadas de convergencia.
Scala é back-end mas é claro que escalabilidade é tratar com elevar em compativel ao ambiente que se sugere.
Falando em diversidade,eu gosto de vários assuntos e até estou lendo algo sobre Object-C a entender aplicações para iPhone.
O que quero finalizar é que temos que fazer combinações e entendermos responsabilidade, existem interesses e estratégias ,de vendor, Players 3 letrinhas e por ai vai , mas temos que ter cultura, não ficarmos rotulados.
Ah tah.. agora acho que faz mais sentido dizer que tá usando Grails no Back-end. :)
É legal isso porque já te dá um controle transactional bem legal e uma interface de Criteria bem bacana também. Fora o suporte de integration teste. Muito bom mesmo usar Grails nesse molde.
Ótimo post !
Infelizmente criou-se uma legião de críticos bem pouco colaborativos ao redor de tudo que é definido pelo JCP, parece que nada é bom. Seja JSF, EJB, JTA, CDI, JavaRepository, JAXB, etc, nada presta. Parece que ser da esquerda, tá na moda. Quando as críticas são fundamentadas, o que é difícil de se ver, acho bem válida as discussões, quando não são, não vale a pena discutir.
Minha opinião quanto a escolha do JSF como framework web é - "depende". Já falei sobre isso em alguns fóruns, mas a verdade é que tem muita coisa a ser discutida quando escolhemos a tecnologia para um projeto.
Como tbm já citei antes por aí, tome como exemplo algumas aplicações da Red Hat. O jBPM Console e o Guvnor (a GUI de gerenciamento para as regras do Drools), utilizam GWT - são aplicações de pouquíssimas páginas, com muita mudança de estado ajax, bem ao estilo Gmail. Neste contexto, o JSF e sua vastidão de componentes mais voltados para formulários, não iriam ajudar muito, a escolha mais sensata para as equipes destes projetos foi o GWT.
Isso não se repetiu com as ferramentas de gerenciamento e monitoração JOPR e JON. Ambas possuiem muitas páginas com abas, gráficos, formulários, Tree-menus, etc. O GWT além de ser mais burocrático para se desenvolver aplicações com estes requisitos, não daria os componentes que existem prontos em outras bibliotecas para formularios JSF. A tecnologia utilizada foi neste caso o JSF mesmo, nítidamente reconhecido pelos componentes Richfaces espalhados pelas páginas da aplicação. Necessidades diferentes, ferramentas diferentes.
Recentemente conversei com uma equipe onde o framework para seu novo projeto era o Struts 1.1. O projeto era pequeno e precisava ser entregue com máxima urgencia. Me perguntaram se valia a pena arriscar JSF + Seam, eu respondi "NÃO". Migrar todo o conhecimento da equipe para uma nova tecnologia, em um projeto que já esta atrasado, simplesmente por estética técnica, eu não recomendo pra ninguém. Neste caso, o skill da equipe e o prazo do projeto tbm contou para a escolha do framework, mesmo com este débito.
Abraços
No mais acho que o que valeu foi a discussão. Olha o tamanho da barra de rolagem, tá magrinha já! O importante aqui foi a colaboração.
Abraço.
E o Seam? O que acha dele?
Gavin King disse que JSF é interessante como um framework para camada de apresentação, principalmente pelo seu ciclo de vida de request extensível e forte modelo de componentes.
Mas e sobre os conceitos de dependency injection, Convention Over Configuration, controle do ciclo de vida dos componentes (EntityManager por exemplo).
Qual sua opinião a respeito do Seam e sobre esses conceitos que o JSF não trata.
Grato pela atenção.
Acho engraçado no Brasil essa bajulação do que é "padrão JCP". Primeiro foi a persistência copiada do Hibernate, depois foram as idéias contidas no Spring copiadas para EJB3 e agora o JSF surgindo como cópia de muitos frameworks web components que já existem a anos no mercado. No começo eu idolatrava tudo que era padrão também, até descobrir que haviam coisas muito melhores por aí, e que ninguem precisa criar classes stubs para usar RMI nem implementar 5 interfaces para controlar propagação de transação. Liberte-se você também! q=]
No que Tapestry é melhor que até hoje não pode entrar na spec do JSF?
Cópia do hibernate? Aceitar um projeto open-source para uma especificação é algo ruim então? Acho que o maior beneficiado nisso foi o autor do Hibernate, ou existe algum processo dele contra o JCP?
Então C# é cópia do Java, que é cópia do C++ que é cópia do C, e assim por diante? não tem nenhum sentido, é dizer que injeção eletrônica é cópia de carburador..
Sobre bajular o JCP, gosto da idéia do governo brasileiro poder influenciar o JCP. Vc não?
Que tal um POST aqui sobre o Tapestry? Seria ótimo para a comunidade.
[]s
Vinicius
Tapestry é um framework open-source (totalmente java) baseado em componentes para o desenvolvimento de aplicações Web (dinâmicas, robustas e altamente escaláveis).
Em vez de negociar com a API Servlet ou com as Ações Struts, o programador Tapestry armazena os dados do usuário em propriedades do objeto e manipula as ações deste usuário com métodos manipuladores de eventos;
Outra grande característica do Tapestry é o uso de templates de páginas HTML;
Cada página é um template HTML contendo tags do próprio HTML;
Ao contrário de páginas JSP, JSTL ou JSF, criando páginas Tapestry é relativamente fácil usar ferramentas para desenvolvimento de design Web, podendo inclusive visualizá-las num Browser sem a necessidade de um servidor web instalado.
[]s
Vinicius
Fiz meu framework: cuspidor_dE__HtMl.php e ele é redondinho!!
Hhuahuahahhauhauh
Capaz, JSF é mto bom, pode não ser perfeito, mas tem mto recurso! E prá quem usava 1.X ele está mto mais prático na 2.0!
Celio, quais os motivos técnicos e mercadológicos do Tapestry no Brasil?
Na empresa que trabalho se usa este framework. Você usa uma roupa pq ela tem motivos mercadologicos ? vc compra um martelo pq ele tem motivos mercadologicos ? desde quando ferramentas precisam de motivos mercadológico ? Você não quer ficar deixar a empresa na mão certo? Bem ainda não vi nenhuma empresa processando o Tapestry por deixá-la na mão.
No que Tapestry é melhor que até hoje não pode entrar na spec do JSF?
Complementando tudo que vc já pode ler do post do Anonimo (Anonimo, por favor mostre a sua cara! =D), além disso o Tapestry possui suporte a serviços de uma maneira simplificado usando IoC. O suporte a Ajax de tapestry é melhor, e isso vc pode comprovar em qualquer tutorial por aí. A componentização é mais simples para Tapestry porque qualquer componente não passa de mais um template.tml + classe.java, com nada especial (http://css.dzone.com/articles/simple-jsf-20-component-vs-tap). Possui live reloading, possui mecanismos para teste implementados diretamente no framework, etc etc etc. Isso faz de JSF uma merda? Claro que não! Mas lembro novamente a frase que coloquei no meu post: "Existem coisas melhores por aí", não falei nada além disso.
Quanto a entrar nas Specs: Hum, aqui fica complicado. Seria uma questão de influência ? No que o Seam é melhor que o Spring e pq o Spring não entrou na specs do JCP mas o Seam entrou ? Fica aí a dica.
Cópia do hibernate? Aceitar um projeto open-source para uma especificação é algo ruim então? Acho que o maior beneficiado nisso foi o autor do Hibernate, ou existe algum processo dele contra o JCP?
Pra mim é a mesma coisa que direitos autorais, vc pode usar livremente, mas cite a fonte pelo menos! A propósito a JPA é fantastica, eu adoro isso e prefiro usar JPA com eclipselink que é a implementação padrão do que com Hibernate, que bem pouco tempo atrás nem implementava 100% da spec.
Então C# é cópia do Java, que é cópia do C++ que é cópia do C, e assim por diante? não tem nenhum sentido, é dizer que injeção eletrônica é cópia de carburador..
C# tem muita diferença de Java, ja programou em C# alguma vez ? É muito mais proximo de C++ do que o próprio Java. É uma ferramenta, é bacana, é usado por pessoas por aí. Uma linguagem não é cópia da outra, é a evolução da outra, do mesmo jeito que Java um dia pode se tornar um novo cobol, e ele vai tornar-se um novo cobol. Se as evoluções não existissem ainda estariamos usando Gols farol quadrado com carburador até hoje. xP
Sobre bajular o JCP, gosto da idéia do governo brasileiro poder influenciar o JCP. Vc não?
Isso é ótimo, mostra que o Brasil está se mostrando lá fora e certamente teremos retorno sobre isso, como já temos atualmente, centenas de empresas por aí que desenvolvem e exportam software. Mas o que isso tem a ver com essa conversa toda? Eu falei alguma vez que o JCP era uma droga ? Acho que vc se equivocou novamente. O JCP tem feito avanços fantásticos, e devemos muito a eles. Você ja usou o BeansBinding que é a tecnologia para ligar interfaces Swing ? É uma droga, vc tem que escrever um monte de código e cada vez que você precisa exibir um bean diferente na tela vc tem que fazer a ligação toda novamente. É uma péssima API, e mesmo assim todos amam, porque é o Padrão JCP. E qual foi a solução encontrada pelo JCP para isso ? Temos que colocar ferramentas para fazer isso automáticamente, ou seja, cada vez mais Java está se tornando uma linguagem orientada a IDEs.
Que tal um POST aqui sobre o Tapestry? Seria ótimo para a comunidade.
Ja que você está me convidando eu farei isso com imenso prazer. Vou preparar um material, mas não se preocupe, não será um comparativo JSF-Tapestry, isso ja existe aos montes na internet e é ridículo. Mas ao invés de criticar vou tentar adicionar à comunidade.
T+ q=]
Bem colocado suas observações frente as indagações fora de conceito do Vinicius Senger.
Não vou postar senão anônimo mesmo porque ao que você observou sobre JCP e Spec já tem empresas consorciadas e envolvida em projetos onde as mesma já se envolve com licitações ou até fechamento sobre soluções politicamente corretas, infelizmente existe ai um cuidado porque como consultor de tecnologia da informação não posso ficar me expondo heroicamente pra não cair em desprestigio com outros leigos que são iludidos , com pseudo-especialista.
Quanto a vender acho que aqui não é o lugar pra isso, ou então muda o discurso pois esse é de péssimo emprego.
Veja ai existe aos montes informações sobre Tapestry mas o Elefante Branco já esta na sacolinha do Papai Noel, e não vai sair de lá tão cedo. ;-)
T+ q=]