Hum? Achei que o objetivo da especificação fosse criar uma api comum, e não uma que suporte peculiaridades de cada uma.
[quote=Guerr@]
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…[/quote]
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.[/quote]
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!
[quote=Guerr@]
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![/quote]
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.
[quote=Botocudo][quote=Guerr@]
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![/quote]
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.
[/quote]
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.
[quote=Guerr@][quote=Botocudo][quote=Guerr@]
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![/quote]
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.
[/quote]
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!
[/quote]
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…
[quote=Botocudo][quote=Guerr@]
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…[/quote]
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.[/quote]
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?
[/quote]
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”.
[quote=Botocudo]
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”.[/quote]
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
[quote=nofan]
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[/quote]
Cara, não compensa discutir com ele, o cara quer bater o recorde do Duran em flames e em falsos nicks.