Arquivo Discussoes de Programacao e Tecnologia 
Bom dia a todos.
Ontem foi finalizado o review da nova JSR 357, padronizando assim no java uma forma de comunicação com as redes sociais, que cada dia mais cresce no mercado corporativo.
http://jcp.org/en/jsr/detail?id=357
No meu ver otima noticia.
att.
Thiago Rolemberg
Parece interessante, mas cada rede social tem suas peculiaridades, além de que todas já possuem APIs em java para acessá-las. Será que precisamos de um foco bem nessa parte? Não sei dizer.
Eu acho que uma API destas iria nivelar por baixo, da mesma forma que o J2ME, que mais atrapalha do que ajuda … (ok, me preparando para as pedradas de algum adorador do J2ME)
Existem diferenças muito grandes entre redes sociais, se a API cobrir apenas o que é comum sera inútil, se for extensível, o código vai ficar tão complexo que vai ser mais fácil escrever do zero …
Claro que podem existir pontos interessantes, como permitir a utilização de qualquer rede social para se autenticar na aplicação, mas já existem bibliotecas para isto, e acho que uma JSR seria perda de tempo.
Os dados disponíveis sobre contatos são tão diferentes em cada uma delas que uma API única seria ou restrita demais ou genérica a ponto de não ser tão útil …
Mas claro, isto é só a minha opinião 
(sim, faz muito tempo que não apareço por aqui )
Olá
Não entendi qual a vantagem. É para ser uma alternativa chapa branca ao Spring Social (que nem vejo muita necessidade)?
Agora você voltou muito ao passado. Quem aqui se lembra para que serve isto?
Abraços
Luca Bastos
Concordo com o Paulo Silveira, todas redes já possuem uma API em java, umas boas outras ruins, mas funcionam.
Precisamos de outros tipos de melhorias…
Observe que a JSR 357 acabou de ser proposta: nesse momento ela passa pelo processo de votação no JCP, para ver se deve continuar ou não no processo. Ela ainda esta pelo menos 1 talvez 2 anos distante de chegar a uma versão da especificação.
É interessante que o Twitter está apoiando essa JSR, junto com a ReHat e a Oracle. Em geral, a maior dificuldade de se conseguir que um padrão “pegue” é trazer os grandes players da área. A presença do Twitter traz um peso gigantesco.
Com a crescente discussão sobre privacidade e controle dos seus próprios dados, uma forma de acesso mais geral a várias redes sociais (possibilitando por exemplo que seus dados pessoais seja migrados de uma para outra, ou replicados) torna essa discussão muito interessante do ponto de vista do usuário final.
Existem inclusive diversos projetos que fazem um pouco disso, o que favorece a razão da padronização. E quem disse que APIs genéricas precisam ser absurdamente complexas? Temos vários exemplos de APIs que “escondem” os detalhes (muitas vezes bem complexos) de bancos de dados, serviços de mensagens, e até mesmo sistemas operacionais inteiros, e que trazem vantagens concretas na sua aplicação. A arquitetura Java é inteira baseada nessa separação de API padrão + implementações específicas + extensões exclusivas, que promovem a padronização, e ajudam a evitar o “menor denominador comum”.
Por outro lado, existe uma discussão de que talvez seja muito cedo para se tentar criar uma especificação dessas, que talvez fosse melhor aguardar mais um tempo, até que esse espaço das redes sociais se consolide um pouco mais.
E você, o que você acha? Dentro de mais ou menos uma semana, o SouJava vai ter que dar o seu voto no comitê executivo do JCP, aceitando ou rejeitando essa proposta de API. Esse é um bom momento para se realizar essa discussão, a sua opinião tem tudo para decidir para onde vai nosso voto.
[]s,
Bruno.
O fato de existirem várias APIs Java para as diversas redes sociais é na verdade uma boa razão para se propor a padronização.
Padronização só funciona quando existem diversas implementações existentes, tentando resolver mais ou menos a mesma coisa (nesse caso, cada uma tenta acessar uma rede social diferente). Se não houvessem várias APIs, vários projetos, não faria sentido se falar em padronização.
Só assim se torna possível criar uma API padrão (“especificação”, “interfaces”), que seria implementada pelas várias APIs específicas (“drivers”, “providers”).
A questão não é se existem outros problemas a serem resolvidos (cada um trabalha no que acha importante, nesse caso, o Twitter por exemplo acha importante trabalhar nisso). A questão é se essa é uma necessidade para aplicações Java, se para o desenvolvedor Java que precisa integrar suas aplicações com redes sociais isso vai ajudar em alguma coisa.
[]s,
Bruno.
Pra mim, spec pra isso é perda de tempo. Perda de tempo do JCP que tem tanta coisa mais importante pra resolver antes de pensar em novas specs (JSR310?).
E os cenários de uso são meio duvidosos… o que exatamente ganha o desenvolvedor ao ter uma padronização pra algo tão pequeno e pontual como acesso a redes sociais. Já somos bem servidos com frameworks como Spring Social.
Se começarmos a padronizar qualquer JARzinho bobo por aí, vamos ter que criar spec pra gráficos (JFreeChart), relatórios (iReports?) etc. [aliás, todos esses casos são mais complexos e mais usados que APIs de redes sociais…]
Enfim, me pareceu totalmente fora do propósito do JCP essa spec.
Acho que seria um esforço sem muito retorno. Ela está mais para a JSR de JDO do que pra JPA. A JPA surgiu de uma necessidade, já havia vários frameworks querendo mapear bancos de dados relacionais. A JDO nasceu top-down.
Cada rede social tem objetivos bem diferentes. Bancos de dados relacionais tem objetivos bem parecidos. Vai acabar sendo uma API super genérica como o JDO, deixando detalhes de fora.
Posso estar pensando besteira, mas se a ideia é padronizar, por que apenas redes sociais? Por que não colocar no mesmo “saco” (API) tudo que se refere a autenticação e autorização? Não seria o caso de rever a especificação do JAAS?
–
Rei
Eu também dispensável uma JSR para isso.
Sou a favor da proposta da API.
O fato de existirem várias APIs Java para as diversas redes sociais é na verdade uma boa razão para se propor a padronização.Padronização só funciona quando existem diversas implementações existentes, tentando resolver mais ou menos a mesma coisa (nesse caso, cada uma tenta acessar uma rede social diferente). Se não houvessem várias APIs, vários projetos, não faria sentido se falar em padronização…
É o poderoso java impondo a padronização nos players do mercado. Concordo que essa JSR ditaria um caminho para todas as redes, assim ao invés de termos VÁRIAS apis funcionando, cada qual do jeu jeito, teríamos uma parão. Sou a favor da API.
(ou até que as redes sociais deixem de existir, assim como foi com as salas de bate-papo, icq e outras febres)
Achei esquisito, mas se dizer que resolve… :?
Para mim tb…mas ainda é cedo para afirmar isso…
Eu acho que, do ponto de vista do desenvolvedor toda especificação é boa…
Eu vejo que é mais uma opção alem do SpringSource…
Por isso, sou sempre a favor!!!
Especificação sempre acima do “proprietarismo”…
Eu entendo que não.
Na verdade vc usaria uma estrategia de JAAS usando alguma implementação do JSR 357.
Os provedores de containers poderiam facilmente acrescentar + essa estrategia dentro das muitas opções existentes…
Bem…
porque disse que acho uma boa noticia:
O que mais cresce no mercado corporativo ultimamente é a utilização de redes sociais, toda vez que temos que desenvolver algo neste aspecto usamos varios jar’s para isso, no meu ver a padronização vem para ajudar, melhorar o que ja temos hoje no mercado.
Também concordo que a JCR tem outros assuntos para resolver, mas hoje trabalho em alguns projetos que usam redes sociais e como acha api, uma para cada rede o codigo acaba ficando horrivel desnecessariamente.
Agora senhores essa é minha opnião, entre diversas que estão sendo dadas aqui.
Eu sou a favor da API.
att.
Rolemberg
Acho realmente que tem muito uso essas APIs de comunicação com twitter e facebook, mas acho que sera frustrante tentar encaixar uma interface única para elas. Elas trabalham de maneira muito diferente, e aí acaba ficando algo meio JDO: tenta mapear tudo, ao mesmo tempo não foca em nada. Em outras palavras, por exemplo, acaba uma API que não consegue fazer tais coisas com facebook (já que é um recurso único dessa plataforma), ai voce precisará utilizar uma API direta.
Sei que bancos de dados relacionais possuem suas diferenças, mas o objetifo final é comum. nas redes sociais isso não ocorre.
Acho realmente que tem muito uso essas APIs de comunicação com twitter e facebook, mas acho que sera frustrante tentar encaixar uma interface única para elas. Elas trabalham de maneira muito diferente, e aí acaba ficando algo meio JDO: tenta mapear tudo, ao mesmo tempo não foca em nada. Em outras palavras, por exemplo, acaba uma API que não consegue fazer tais coisas com facebook (já que é um recurso único dessa plataforma), ai voce precisará utilizar uma API direta.
Sei que bancos de dados relacionais possuem suas diferenças, mas o objetifo final é comum. nas redes sociais isso não ocorre.
mas não seria responsabilidade dos lideres da JSR viabilizar oq vai entrar como padrão e o que vai ser extensão proprietária?
Sim, com certeza. Mas parece que quase tudo viraria extensão proprietária! :). Aquela api de data mining acho que teve fim parecido, creio que a versão 2.0 tenha sido abandonada por causa disso. Eu fiquei surpreso quando JDO conseguiu chegar no 2.0.
Vc tem razão paulo…pode acontecer isso sim!
Vamos ver oq vai dar…
Faço das suas as minhas palavras.
Faço das suas as minhas palavras.
Acho que não é porque há a necessidade de pensar em coisas importantes que essa não seja importante também…
Mais uma especificação inútil.
Redes sociais tem propostas, funcionalidades e focos diferentes.
Faço das suas as minhas palavras.
Acho que não é porque há a necessidade de pensar em coisas importantes que essa não seja importante também…
A questão de eu ter apoiado o comentário do Sergio, Mitidiero, é que estão pensando essa questão do Date há muuuuuuito tempo…
A questão de eu ter apoiado o comentário do Sergio, Mitidiero, é que estão pensando essa questão do Date há muuuuuuito tempo…
Ou seja , o pessoal discutindo se vamos incluir Facebook ou Twitter e a gente aqui em baixo se lascando usando java.util.Date.setDate, que vai de 1 até 31 e a java.util.Date.setMonth, que vai de 0 até 11 !!! :shock:
A questão de eu ter apoiado o comentário do Sergio, Mitidiero, é que estão pensando essa questão do Date há muuuuuuito tempo…Ou seja , o pessoal discutindo se vamos incluir Facebook ou Twitter e a gente aqui em baixo se lascando usando java.util.Date.setDate, que vai de 1 até 31 e a java.util.Date.setMonth, que vai de 0 até 11 !!! :shock:
Pessoal, as coisas correm em paralelo. São equipes diferentes, ideias diferentes e cada uma com usa dinâmica e grupo de interesse. A ideia de abrir as discussões é justamente essa, pra que todo mundo possa participar e escolherem as que se tornarão specs. Da mesma forma que estão discutindo a JSR 357, podem participar da discussão sobre a nova API pra data ou pra campos monetários.
Oi Marcos.
Entendo que pessoal esteja exagerando, mas se for assim, deveríamos aceitar tudo como especificação, já que são todos times paralelos. Mas sabemos que na verdade há sim um desgaste, um limite para o número de specs correndo concomitantemente. Não por acaso o Java 7 foi quebrado em dois, dado o número grande de specs que gostariam de ter colocado nele. Se optarmos por essa JSR e ela entrar no Java EE 8 (!), estaremos preterindo alguma outra.
Olá Pessoal,
Na minha opinião, só o fato dessa JSR surgir como “assunto” já é um grande avanço nesse JCP, tendo como comparação a lentidão ao padronizar “novas” tecnologias no passado (JPA).
Acho que o Bruno Souza tocou nos pontos relevantes no quesito “Por que padronizar?”:
Já outro ponto também relevante é o qual o Paulo se referiu.
Sim, redes sociais tem propostas, funcionalidades e focos diferentes…, Mas também, elas tem alguns pontos em comum e o mais importante é: elas são redes sociais.
Assim como banco de dados guardam dados relacionados a uma “entidade” (mesmo que não sejam BD relacionais), redes sociais guardam dados e relacionamentos referentes a uma pessoa.
E sabe o que as redes sociais tem em comum (na minha humilde opinião)?
Então a questão é: obter essas informações em comum através de uma API padronizada é ou não vantajoso para aplicações Java?
Esperar as redes sociais se consolidarem? Na minha opinião não, basta lançar uma versão básica, nem que seja só para autenticar em redes. Afinal de contas, praticamente todo mundo gostaria de pelo menos se autenticar com a rede que mais usa (usuários).
Então, uma aplicação Java não “apreciaria” fazer isso de uma forma fácil e padronizada?
Vou citar o GUJ e Concrete Solutions como exemplo…
Simplificando, para mim, fóruns e listas= web 1.0, redes sociais = web 2.0. Por exemplo, vamos transformar o GUJ em 2.0, ou seja, em uma rede social. Por que não? Bom, vamos adicionar as features:
Espere, qual é mesmo o objetivo e o propósito dessa rede?
E quanto as features? Agora é só adicionar o que toda rede social tem em comum (timeline, lista de pessoas relacionadas, etc).
Pronto o GUJ virou uma rede social e agora eu quero fazer com que usuários do GUJ possam comentar no meu blog usando o login deles, digamos que o blog seja: http://blog.concretesolutions.com.br/ e que ele seja em Java ;-). Assim, usando o login do GUJ, o comentário será feito e isso será exibido na minha timeline do GUJ.
É isso, acho que a padronização seria uma ótima ideia, pois eu iria querer exatamente o que a solicitação comunica:
This specification proposes to provide an API for accessing social information networks, both Public (Facebook, Twitter, Google+, LinkedIn, Xing, Yammer,…) and Corporate, e.g. within
the Enterprise or Institution (University, Hospital, etc.)…
Simplificando, para mim, fóruns e listas= web 1.0, redes sociais = web 2.0. Por exemplo, vamos transformar o GUJ em 2.0, ou seja, em uma rede social. Por que não? Bom, vamos adicionar as features:…
Pronto o GUJ virou uma rede social e agora eu quero fazer com que usuários do GUJ possam comentar no meu blog usando o login deles, digamos que o blog seja: http://blog.concretesolutions.com.br/ e que ele seja em Java ;-). Assim, usando o login do GUJ, o comentário será feito e isso será exibido na minha timeline do GUJ.
Mas bem como voce falou, pra web 2.0, e pra essas redes sociais, fazemos a integração usando 99% de codigo client side, via javascript, e não server side. Realmente me parece que o uso seria bem pequeno.
Paulo,
Para um caso como o de autenticação que citei, sim é verdade, podemos fazer client side, aliais, podemos fazer muito com javascript+rest nesse caso. Mas a questão é:
Seria bom ter como fazer esse caso simples de autenticação na API do Java, sim ou não?
Ou seja, desenvolvedores Java vão precisar apenas saber essa API para fazer isso e pronto (Java nesse caso trouxe produtividade, contou ponto em sua aplicação que faz uso do Java?)
Mas esse é o caso simples, coloquei só para ilustrar, …, Na minha visão, e acredito que na de muitos, as redes sociais, como já disse, também podem ser consideradas, em certos momentos de interesse, como sendo um banco de dados, ou melhor, um repositório de informações.
Então, por exemplo, quando eu consigo um login via Java (Server side ou não), se essa API me permitir buscar os relacionamentos dessa pessoa logada, e assim obter os e-mails, fotos, perfis, etc, das pessoas relacionadas a esse login que acabei de efetuar, …, vou ficar muito feliz se, a partir daí, já conseguir processar toda esta informação que eu quero e busquei nesse repositório via Java.
E se a API fornecer acesso a informações que um aplicativo para o Facebook tem, por exemplo? Já da para imaginar que isso agrega valor ao Java sim.
Como o Bruno Souza falou:
E se o Google também entrar nessa, na minha opinião, vai ser meio caminho andado.
O Google criou sua própria rede social e integrou no Android e a Apple em dois tempos integrou o twitter no iOS e no MacOS, enquanto isso o povo do Java está preocupado em padronizar todas as redes sociais existentes e que ainda virão a existir em uma API!
Fazer o que, isso é que dá quando a plataforma é adotada por palestrantes e consultores mais preocupados em mostrar como eles são espertos por criarem uma especificação mirabolante ao invés de uma solução que simplesmente funcione.
É impressão minha ou de uns tempos pra cá vem surgindo um monte de usuários novos, com menos de 5 posts, que só aparecem pra trollar e depois nunca voltam? E sempre com o mesmo padrão de conversa e português…
Eu ja dei minha opinião e gostaria de saber quando sera o dia do voto e qual sera o posicionamento do SouJava?
To curioso pra saber como vão fazer isto… Fazer uma integração com qualquer rede é geralmente simples, porem é só vir a porcaria chamada facebook que uma coisa simples se transforma em uma coisa complexa. O facebook não tem nenhum servicinho como conectar, postar, compartilhar, etc… Tem uma porcaria chamada graph api e ainda vc é obrigado a usar a interface dele para logar, se quiser fazer uma app com a sua interface de login é praticamente inviavel… Facebook não segue padrões, fazem as coisas do jeito que da na telha deles e foda-se o resto. Basta vc ver a simplicidade da api do Twitter e a complexidade da api do facebook que é cheio de mimimi e pouco produtivo.
Interessante, tenho reparado nisso também.
Enquanto alguns trabalham na Stack da Typesafe outros ficam pensando em padronizar API de redes sociais, é isso ai!
Imagino se tem alguma JSR para padronizar NoSQLs… Deve ter a mesma falta de propósito e motivo técnico que esta aqui.
Imagino que nosql não venda tantos livros e palestras.
Uma API extremamente genérica e uso server-side.
Integração com Redes Sociais: Você está fazendo isso errado! :shock:
tbm nao sei o q esperar dela
mas padronizando o login pra facilitar o Sigle Sign On
já seria algo
tbm nao sei o q esperar dela
mas padronizando o login pra facilitar o Sigle Sign On
já seria algo
Rapha, você já precisou disso server side? Na maioria absoluta dos sites, só precisamos da API do facebook ser acessada via javascript. tudo client side.
tbm nao sei o q esperar dela
mas padronizando o login pra facilitar o Sigle Sign On
já seria algoRapha, você já precisou disso server side? Na maioria absoluta dos sites, só precisamos da API do facebook ser acessada via javascript. tudo client side.
Posso imaginar dezenas de motivos para alguém precisar fazer isso server side.
Agora do ponto de vista das redes sociais vc tem razão, não vejo qual motivo eles exporiam tal api. A maioria dessas redes tem modelo de negócio baseado em publicidade e servidores não clicam em ads.
Penso que o mais correto seria usar WebServices e não uma API especifica.
Depois de ler a JSR inteira modifico meu posicionamento e entendo ser muito benéfico para a comunidade essa padronização
Pois é…quantos outros que leram antes de comentar? kkkkk
Bom, eu formalizei a minha opnião:
Pois é…quantos outros que leram antes de comentar? kkkkk
a unica coisa que me preocupa alem de tudo que foi falado é a eterna imparcialidade no verdadeiro interesse de uma API unica pra tudo isso, de fato ha algo de estranho quando percebe-se que os specification leads trabalham numa empresa de marketing digital.
Specification Leads: Werner Keil, Antoine Sabot-Durand
E-Mail Address: [email removido]
[email removido]
tendencioso.
a unica coisa que me preocupa alem de tudo que foi falado é a eterna imparcialidade no verdadeiro interesse de uma API unica pra tudo isso, de fato ha algo de estranho quando percebe-se que os specification leads trabalham numa empresa de marketing digital.Specification Leads: Werner Keil, Antoine Sabot-Durand
E-Mail Address: [email removido]
[email removido]tendencioso.
Certo, mas em algum lugar eles tem que trabalhar né?
Pois é…quantos outros que leram antes de comentar? kkkkk
A questão não é se a integração com redes sociais é positiva, e sim que ela não deve ser feito por meio de padronização, já que esta na cara que quando a especificação ficar pronta o simples conceito de rede social já vai ter mudado, adotado outros aspectos de interação, de tal forma que, o que hoje é considerado objeto da especificação vai estar defasado.
Sinceramente, os que defendem padronização deveriam se ater ao mercado corporativo, porque de software para consumidor eles não entendem nada.
…
Acho que devemos votar e deixar ela continuar para ver qual o rumo…
Bem, hoje é o último dia para votarmos, e essa discussão tem sido bem interessante, tanto aqui quanto nas discussões internas do SouJava e na lista do programa Adote uma JSR.
Tentando juntar os diversos votos, acabei de enviar minha proposta de voto para a lista de padronizacao:
http://java.net/projects/soujava/lists/padronizacao/archive/2012-03/message/1
A votação interna ainda está acontecendo, e pode mudar a posição. Eu informo aqui o resultado final da votação.
De qualquer forma, acho que o mais importante é que essa discussão aconteça: Java é uma tecnologia na qual os desenvolvedores podem de fato participar da evolução da plataforma. Quanto mais discussões como essa acontecem, mais participação todos nós temos no processo.
Parabéns a todos pela vontade e esforço em se envolver e participar.
Bruno.
Ola Bruno,
Vc poderia repassar qual é exatamente a lista que o pessoal do SouJava discute as votações para JSR?
Ola Bruno,
Vc poderia repassar qual é exatamente a lista que o pessoal do SouJava discute as votações para JSR?
O SouJava mantém uma lista pública de discussão sobre padronização:
http://java.net/projects/soujava/lists/padronizacao/
O grupo do programa “Adopt a JSR” do SouJava participa mais ativamente:
Além disso, as dicussões acontecem na reunião semanal e na lista interna do grupo.
[]s,
Bruno.
A padronização das APIs não significa que as redes sociais precisarão ser todas da mesma forma. Cabe a quem for trabalhar na JSR reconhecer os pontos onde estão essas diferenças e criar uma API que suporte as peculiaridades de cada uma.
Isso daria um bom artigo para a MundoJ… Alguém se habilita?
O fato de existirem várias APIs Java para as diversas redes sociais é na verdade uma boa razão para se propor a padronização.Padronização só funciona quando existem diversas implementações existentes, tentando resolver mais ou menos a mesma coisa (nesse caso, cada uma tenta acessar uma rede social diferente). Se não houvessem várias APIs, vários projetos, não faria sentido se falar em padronização…
É o poderoso java impondo a padronização nos players do mercado. Concordo que essa JSR ditaria um caminho para todas as redes, assim ao invés de termos VÁRIAS apis funcionando, cada qual do jeu jeito, teríamos uma parão. Sou a favor da API.
(ou até que as redes sociais deixem de existir, assim como foi com as salas de bate-papo, icq e outras febres)
Java é irrelevante para esse mundo. Ninguém anda fazendo webapp moderninha com Java. No máximo, no máximo nego usa uma linguagem que roda na JVM como Scala. Logo uma especificação de uma JSR é irrelevante para esse mercado. É perda de tempo.
Talvez a preocupação deveria ser em fazer a linguagem melhor, consertar porcarias como java.util.Date, consertar coisas estúpidas como não ter construções sintáticas adequadas para coleções, forçando você a usar métodos. Aí, talvez, e só talvez fosse interessante para startups usar java para construir produtos modernos.
Será mesmo? Dê uma olhada no índice TIOBE e verá que Java ainda é a linguagem mais popular do mundo. Se considerar linguagens para aplicações web, atrás vem o C# que tem metade dos desenvolvedores que Java e depois PHP que não tem nem 1/3.
Aplicações de redes sociais geralmente utilizam arquiteturas do tipo Cloud Computing, onde Java também é uma linguagem amplamente suportada e utilizada…
Hum? Achei que o objetivo da especificação fosse criar uma api comum, e não uma que suporte peculiaridades de cada uma.
Será mesmo? Dê uma olhada no índice TIOBE e verá que Java ainda é a linguagem mais popular do mundo. Se considerar linguagens para aplicações web, atrás vem o C# que tem metade dos desenvolvedores que Java e depois PHP que não tem nem 1/3.Aplicações de redes sociais geralmente utilizam arquiteturas do tipo Cloud Computing, onde Java também é uma linguagem amplamente suportada e utilizada…
Acho que ele quis dizer mundo das redes sociais…
Java é popular no mercado corporativo mas se vc falar em criar produto em escala web (como uma rede social) usando Spring ou JBoss, nego vai rir da sua cara.
Hum? Achei que o objetivo da especificação fosse criar uma api comum, e não uma que suporte peculiaridades de cada uma.
Na verdade a API é comum, porém ela tem que suportar as diferenças! Da mesma forma que uma API para acesso a bancos de dados precisam suportar as diferenças de cada um através de uma mesma API. Esse é o real desafio de se criar essa API!
Na verdade a API é comum, porém ela tem que suportar as diferenças! Da mesma forma que uma API para acesso a bancos de dados precisam suportar as diferenças de cada um através de uma mesma API. Esse é o real desafio de se criar essa API!
Mas o objetivo do JSR não é definir APIs, e sim uma especificação que os fornecedores precisam implementar para serem considerados compatíveis. E isso inclui o mínimo comum.
A especificação não tem papel de levar em conta peculiaridades de cada fornecedor.
Claro, cada fornecedor decide implementar sua API como quiser, inclusive se ela vai ser compatível com alguma especificação.
Bom dia Senhores…
Como esperado por alguns a API não foi aprovada:
https://blogs.oracle.com/theaquarium/entry/social_media_jsr_357_not
Me surpreendeu algumas empresas que investem em redes sociais não aprovar.
Na verdade a API é comum, porém ela tem que suportar as diferenças! Da mesma forma que uma API para acesso a bancos de dados precisam suportar as diferenças de cada um através de uma mesma API. Esse é o real desafio de se criar essa API!Mas o objetivo do JSR não é definir APIs, e sim uma especificação que os fornecedores precisam implementar para serem considerados compatíveis. E isso inclui o mínimo comum.
A especificação não tem papel de levar em conta peculiaridades de cada fornecedor.
Claro, cada fornecedor decide implementar sua API como quiser, inclusive se ela vai ser compatível com alguma especificação.
Me permita discordar…
Vou dar um exemplo: imagine que em redes sociais diferentes os usuários possam realizar ações diferentes.
Da forma como você está colocando, existiria uma inteface apenas com métodos que representem as ações em comum.
Uma outra alternativa seria modelar cada ação como um comando (do padrão Command). Daí em uma rede social você poderia acessar quais são as ações disponíveis (talvez com algumas informações que permitissem você ter informações de cada uma) e invocar a que você deseja.
Esse exemplo mostra como uma API, apesar de padronizada, pode suportar diferenças!
duvido muito que o facebook entre no meio disto já que ele não permite nada server-side, com ele é tudo client-side.
Na verdade a API é comum, porém ela tem que suportar as diferenças! Da mesma forma que uma API para acesso a bancos de dados precisam suportar as diferenças de cada um através de uma mesma API. Esse é o real desafio de se criar essa API!Mas o objetivo do JSR não é definir APIs, e sim uma especificação que os fornecedores precisam implementar para serem considerados compatíveis. E isso inclui o mínimo comum.
A especificação não tem papel de levar em conta peculiaridades de cada fornecedor.
Claro, cada fornecedor decide implementar sua API como quiser, inclusive se ela vai ser compatível com alguma especificação.
Me permita discordar…
Vou dar um exemplo: imagine que em redes sociais diferentes os usuários possam realizar ações diferentes.
Da forma como você está colocando, existiria uma inteface apenas com métodos que representem as ações em comum.
Uma outra alternativa seria modelar cada ação como um comando (do padrão Command). Daí em uma rede social você poderia acessar quais são as ações disponíveis (talvez com algumas informações que permitissem você ter informações de cada uma) e invocar a que você deseja.
Esse exemplo mostra como uma API, apesar de padronizada, pode suportar diferenças!
O problema não é conseguir fazer, mas isso ser útil.
Essas apis tem que atender diversas linguagens e ninguém iria levar isso a sério como no JPA. Incrível q os únicos q precisam desse padrão é o ‘pessoal Java’.
Na verdade o único pessoal que realmente se preocupa em padronizar alguma coisa é o “pessoal Java”. Acredito que essa filosofia tem dado muito certo nos últimos anos e é um dos grandes diferenciais da plataforma Java.
Independente do mérito da JSR, a discussão foi positiva, inclusive o resultado das votações (recomendável ler os comentários de todos os votantes).
Gostaria de saber a posição do SouJava sobre JSRs mais relevantes, como a nova API de data, dinheiro, lambda, o novo JSF, etc.
não achei nada positivo…tivemos mais comentários questionando a credibilidade e a filosofia da plataforma do que os pontos da JSR em sí…
Me desculpem amigos pela sinceridade, mas é desanimador…
Será mesmo? Dê uma olhada no índice TIOBE e verá que Java ainda é a linguagem mais popular do mundo. Se considerar linguagens para aplicações web, atrás vem o C# que tem metade dos desenvolvedores que Java e depois PHP que não tem nem 1/3.Aplicações de redes sociais geralmente utilizam arquiteturas do tipo Cloud Computing, onde Java também é uma linguagem amplamente suportada e utilizada…
Acho que ele quis dizer mundo das redes sociais…
Java é popular no mercado corporativo mas se vc falar em criar produto em escala web (como uma rede social) usando Spring ou JBoss, nego vai rir da sua cara.
Cara ele falou de aplicações em redes sociais e essas usam muito cloud que tem java como forte, quanto ao backend das redes sociais eles não usam soluções java padrão mas usam soluções java que deveram ser padronizadas em breve como hadoop e cassandra na area de nosql e mapreduce.
Facebook, twitter e Google não tem seus próprios datacenters? :shock:
Isso é novidade pra mim. Poderia dar mais detalhes?
Facebook, twitter e Google não tem seus próprios datacenters? :shock:
Isso é novidade pra mim. Poderia dar mais detalhes?
Claro que posso, estou aqui para ajudar a tirar suas duvidas!
Obrigado, mas acho que vc confundiu meu post com outro.
Perguntei qual rede social usa Java, e se possível detalhes sobre sua arquitetura “cloud”.
Obrigado, mas acho que vc confundiu meu post com outro.
Perguntei qual rede social usa Java, e se possível detalhes sobre sua arquitetura “cloud”.
Sua incapacidade de ler um texto reflete a educação no brasil!
quando ele falou de arquitetura cloud, o guerra se referiu as aplicações que rodam na rede social e não a própria rede social.
quanto a usar java em redes sociais posso citar alguns exemplos depois pra aumentar seu conhecimento começando por esse
Sua incapacidade de ler um texto reflete a educação no brasil!
quando ele falou de arquitetura cloud, o guerra se referiu as aplicações que rodam na rede social e não a própria rede social.quanto a usar java em redes sociais posso citar alguns exemplos depois pra aumentar seu conhecimento começando por esse
http://www.infoq.com/br/news/2011/04/twitter-blender
Cara, não compensa discutir com ele, o cara quer bater o recorde do Duran em flames e em falsos nicks.