Usar o Padrão ou a(s) Alternativa(s)

Eu sou bastante a favor de usar implementação de uma JSR quando a licença é compatível.

Acredito mais na padronização (e especialmente na manutenção de compatibilidade) nesses casos.

Tive a experiência de trabalhar com portlets quando ainda estava sendo desenvolvida a JSR, na época trabalhando com a solução da IBM, e quando mudava a versão acabava tendo que atualizar meus portlets porque eles paravam de funcionar.

Claro que algumas frameworks “não-oficiais” são bastante sérias e tentam evitar tais problemas, porém é como se as implementações de JSRs tivessem um “selo de qualidade” a mais nesse sentido.

Oi, Bani!

Por algum motivo além de no futuro não precisar adicionar bibliotecas de terceiros ao software? Muitos garantem compatibilidade entre as versões.

Aqui você tocou no X da questão. Que as implementações das JSR’s têm um “selo” a mais é indiscutível, mas será que resolvem o problema da melhor forma? :roll:

Pesa, desde que se considere o padrão uma solução eficaz.

RafaelRio:

um professor universitário, por exemplo, poderia / deveria ensinar alguma solução só pelo fato de ser a implementação de uma JSR?

Não; deveria ensinar o que for mais apropriado.

Apenas como exemplo, pense em EJB 2.x e Spring

A questão é se o padrão resolve o problema da melhor forma. No caso da JSR-295, eles estão praticamente reestruturando o código inteiro, desde que o Shannon assumiu a liderança.

Além disso, o escopo da JSR não é um match exato com os outros frameworks. O genesis, por exemplo, cobre boa parte do escopo da JSR-295, 296 e 303.

Por algum motivo além de no futuro não precisar adicionar bibliotecas de terceiros ao software? Muitos garantem compatibilidade entre as versões.

Simplesmente pelo fato de ser “padrão”. Isso costuma dizer que já discutiram o suficiente e “fecharam” a API, naquele sentido de “fechado para modificação mas aberto para extensão” do Bertrand Meyer.

Como eu disse, eu acredito mais nesses casos. Não que outras implementações sejam ruins.

mister__m:

RafaelRio:

um professor universitário, por exemplo, poderia / deveria ensinar alguma solução só pelo fato de ser a implementação de uma JSR?

Não; deveria ensinar o que for mais apropriado.

Apenas como exemplo, pense em EJB 2.x e Spring :-)

Na verdade eu pensei em EJB 2.x, Spring e EJB 3.0.

Agora, falando sério, nem sempre a escolha é tão óbvia quanto Spring vs. EJB 2.0, tornando a questão sobre o que é “mais apropriado” bastante subjetiva.

E tem outra coisa: geralmente é difícil aprender a utilizar bem um framework. Então, mesmo em novos projetos, largar um framework previamente utilizado em favor de uma implementação de uma JSR pode ser custoso.

Passo a primeira, vamos a segunda.

Professor universitário ensinar framework? Eu penso que “solução” nenhuma deve ser ensinada na faculdade, pelo simples fato de que ela não será mais “solução” daqui a 5 anos (e “solução” é um termo que o departamento de marketing da microsoft adotou ;)).

Faculdade não deveria ensinar tecnologia, não é o propósito. Porém, claro, é impossível ensinar conceitos teóricos sem alguma ilustração prática, que envolverá tecnologia do aqui e agora. Penso que o professor deve utilizar a tecnologia mais apropriada, seja porque ele domina ou seja porque é otimizada para o problema em questão. Implementar uma JSR não deve ser um fator que orienta uma decisão desse tipo.

Agora, mudando a questão: ensinar tecnologia pela tecnologia em si? Em um curso superior? Só porque implementa uma JSR? Não…

bzanchet:

Passo a primeira, vamos a segunda.

Professor universitário ensinar framework? Eu penso que “solução” nenhuma deve ser ensinada na faculdade, pelo simples fato de que ela não será mais “solução” daqui a 5 anos (e “solução” é um termo que o departamento de marketing da microsoft adotou ;)).

Faculdade não deveria ensinar tecnologia, não é o propósito. Porém, claro, é impossível ensinar conceitos teóricos sem alguma ilustração prática, que envolverá tecnologia do aqui e agora. Penso que o professor deve utilizar a tecnologia mais apropriada, seja porque ele domina ou seja porque é otimizada para o problema em questão. Implementar uma JSR não deve ser um fator que orienta uma decisão desse tipo.

Agora, mudando a questão: ensinar tecnologia pela tecnologia em si? Em um curso superior? Só porque implementa uma JSR? Não…

Tudo bem, essa pergunta sobre um professor universitário ensinando frameworks foi péssima. Eu só estava tentando dar mais peso à decisão de usar o padrão ou uma das alternativas existentes.

Troque professor universitário por um instrutor de cursos técnico, consultor, o que for. Ok?

Frameworks aparecem porque alguem precisa deles. Frameworks para fazer a mesma coisa existem. Quando são muitos, alguem quer padronizar e nasce uma JSR. Ou então, o framework é tão util que nasce a ideia de o incoorporar ao padrão.

Por exemplo o Log4J é o padrão de fato para logging. Embora o java tenha o seu ppr logging ele nasceu depois do Log4j e não tem as mesmas capacidades (é o que dizem, nunca usei o java logging). A pergunta é, porque a Apache simplesmente não deu o Lo4J para ele virar o java logging ?
Este é um exemplo em que o padrão java não é o padrão de fato ( o que todo o mundo usa). E isso causa problemas que levaram à criação do Commons Logging.

Vc pode implementar o seu ppr framework de logging, mas convenhamos que na realidade vc desenvolverá uma casca em cima do log4j , commons e java logging de forma que possa escolher qual usar ou usar todos ao mesmo tempo.

Uma JSR nem sempre é a melhor solução para o dominio do problema, ja que existem outros pesos. Por exemplo, a JSR-275 de unidades de medida e medidas obriga a atrelar uma grandeza a todas as unidades e medidas na forma de tipo generico. Isso foi baseado na implementação JScience que foi a base para JSR. A verdade é que essa amarração é inútil já que ao fazer contas ela não se propaga. E tem vários outros detalhes …
A questão é que foi baseada em algo pronto, os lideres da JSR são quem tinha isso pronto. O interesse pela JSR parece não ser tão grande assim (embora esteja prevista para entrar no java 7). Tudo isto produz uma API “menos que otima”. Claro que existem outros fatores a considerar numa JSR além da pureza do dominio.

A JSR 310 (datas e tempos) começou pela ideia usada no Joda Time, mas está bem mais afastada dessa API. Embora tenha as sua idiossincrasias relativamente a nomes de classes e métodos evolui bastante comparada com API do joda. Evoluiu no sentido de ficar mais perto do dominio e mais longe de uma API “solução rápida”

Mas veja, os intervalos de tempo definidos na 310 não são medidas no conceito da 275.
Logo aqui se entende que a falta de entrozamento levará a alguém criar outra API que enxergue as coisas sob uma optica só (tal como elas são na realidade uma coisa só) … que num futuro poderá dar origem a uma JSR

Ou seja, preferir uma JSR a uma implementação de terceiros não tem regras. Vc usa a que gostar mais, a que melhor satisfizer as suas necessidades. E tem o fator experiência tb. Tlv se todo o mundo não tivesse viciado no Log4j a java loggging API tivesse uma chance…

Respondendo à sua pergunta diretamente:
Sim, pesa.Mas apenas quando os outros fatores são um empate (simplicidade, rapidez, disseminação, etc).

Nesse caso eu diria que a demanda do mercado é o fator de maior importância. Vou ter que concordar com o Michel, porque implementar uma JSR implica, na maioria dos casos, em maior demanda. Logo, implementar uma JSR provavelmente seria um fator de peso, sim.