O Programa criado pelo SouJava e London Java Community, O Adopt a JSR está a todo vapor, a idéia inicialmente proposta pelo JUG Brasileiro esta atravessando o mundo e nossos esforcos para atrair a atenção do publico estão dando cada vez mais resultados. Obrigado a todos os colaboradores do SouJava e também todos os leitores do nosso site que tem contribuido com a inciativa.
Hoje vamos aprensentar a JSR 357 – Social Media API.
Esta JSR esta causando grande polemica na comunidade e por isso resolvemos apresentar os fatos e abrir o topico para discução pois o SouJava vai enviar o seu voto dentro de poucos dias, e a sua opinião pode determinar o nosso voto.
A JSR 357 foi criada para definir uma API generica para acessar as os dados de todas as redes sociais pagas e/ou publicas como (Facebook, Twitter, Google+,LinkedIn, Xing, Yammer entre outras).
Os Spec Leads idealizadores da JSR sao: Werner Keil e Antoine Sabot-Durand. A votação para a aprovação ou rejeição da JSR teve inicio dia 6 de Marco de 2012 e as metas para esta JSR sao bastante agressivas levando em conta que existe a previsao de liberar uma versao final no primeiro semestre de 2013.
Voce pode observar que a JSR 357 acabou de ser proposta, o que significa que nesse momento ela passa pelo processo de votação dentro do JCP, para ver se deve continuar ou não no processo. A JSR 357 esta dando o que falar, principalmente porque conta com o apoio do Twitter, junto com a RedHat e Oracle. Por si só, o apoio desses grandes players se mostra muito interessante e traz uma grande perspectiva de um futuro promissor para a JSR, tendo em vista que a maior dificuldade esta em conseguir apoio de grandes players do mercado.
Atualmente vemos uma crescente discução sobre privacidade e controle dos dados dos usuarios nas redes sociais, e uma forma de obter esse controle é criando um padrao onde todas as redes sociais possam conversar entre si, e abrir a possibilidade de serem efetuadas trocas dados entre elas. Possibilitando por exemplo que seus dados pessoais sejam migrados do facebook para o Google+, ou apenas replicados. Isso traz grande beneficio para o usuario final que não vai mas precisar ficar em uma rede social porque se mudar, perde tudo que foi escrito e feito durante anos.
Já existem projetos que tentam realizar esse tipo de tarefa, porem este esforço esta ligado a empresas e membros individuais. O fato de existirem várias APIs Java de diferentes players, funcionando de diferentes maneiras para as diversas redes sociais é na verdade uma boa razão para se propor a padronização.
Somente atravez da padronizacao é que se torna possível criar uma API padrão (“especificação”, “interfaces”), que seria implementada pelas várias APIs específicas (“drivers”, “providers”).
A Padronizacao so funciona quando já existem diversas implementacoes no mercado orientadas a desenvolver/resolver um mesmo problema. Por si só, o fato de existirem varios projetos tentando fazer a migracao de dados, e tantas API’s de rede sociais distintas ja caracteriza que nos precisamos de um padrao.
Por outro lado há quem diga quem diga que o resultado dessa API sera apenas uma API generica e que será apenas mais um esforço que nao tera nenhum resultado valido para a comunidade.
Para abordar esse assunto devemos levar em conta que o proprio mercado conta com diversas outras API’s que “escondem” os detalhes mais complexos de conexao com banco de dados, servicos de mensageria ou até mesmo sistemas operacionais inteiros. O resultado final acaba trazendo vantagens concretas para uns, e nenhuma vantagem para outros. A arquitetura do Java funciona baseada nessa separação de API padrão + implementações específicas e extensões exclusivas, que promovem a padronização, e ajudam a evitar o “menor denominador comum”.
A questão que devemos focar, nao é: Se existem outros problemas a serem resolvidos ou se essa é, ou nao, a prioridade no JCP. Devemos focar e saber se essa API vai trazer para o desenvolvedor Java facilidades para integrar suas aplicacoes com redes sociais.
E você, o que você acha? Dentro de mais ou menos uma semana, o SouJava vai ter dar o seu voto no comitê executivo do JCP, aceitando ou rejeitando essa proposta de API. Esse é um otimo momento para abrirmos o tópico para discussão, e a sua opinião tem tudo para decidir para onde vai nosso voto.
Quer participar ?
Veja os detalhes na página Adopt a JSR do SouJava, se inscreva na lista de padronização, escolha a JSR que mais interessa a você e preencha o formulário para participação.
Veja também quem já participa do JCP representando a comunidade Java Brasileira!
Vale a pena participar ?
A participação do Brasil na comunidade internacional de TI está cada vez maior e mais efetiva, mas sempre pode evoluir. Para isso é fundamental que cada um de nós estenda sua participação. Participar significa aumentar a participação no projeto local, no grupo de usuários local, nos eventos, nas listas de discussão. Participar pode significar ler, aprender e compartilhar, opinar, criticar, testar, documentar, enfim, fazer o mecanismo de informações funcionar.
Se você ainda tem dúvidas se vale a pena participar, assista o vídeo A Era da Participação com Bruno Souza, conhecido como Java Man, fundador do SouJava e representante do SouJava no Executive Comittee do JCP.
Profissao Java – A Era da participacao – Bruno Souza.
JCP, SouJava adopt a jsr, google, iniciativa soujava, java community, java community process, java jsr, jcp, jsr 357, JSR 357 – Social Media API, jug brasileiro, maior jug brasileiro, soujava, thomas modeneis, werner keil
No último dia 14, o SouJava participou da votação do “Final Release” da JSR #348: Towards a new version of the Java Community Process mantendo linha adotada na votação da “Public Review” que considerou esta JSR, um passo importante na evolução do JCP.
O voto final do SouJava destaca a importância da abertura e transparência nas discussões do JCP, conforme segue:
“A JSR-348 baseia-se na experiência em abertura que várias JSRs existentes iniciaram, tornando abertas e transparentes as decisões do JCP como um todo. Este é um passo importante para promover a transparência e a participação no JCP. Com isso, a Comunidade Java pode ter uma participação muito melhor nas discussões sobre o JCP.next, e agora podemos abordar as questões mais difíceis do JCP em uma discussão inclusiva e transparente.”.
Na site do JCP você pode conferir os votos dos demais participantes em JSR #348: Towards a new version of the Java Community Process – Final Approval Ballot.
O SouJava está no Facebook. Acompanhe o Twitter do SouJava, e participe da discussão com a hashtag #SJJCP.
O JCP Program Awards está na sua 9ª. edição e atualmente é composto por três categorias: “JCP Member/Participant of the Year”, que reconhece o membro do JCP que promoveu o impacto positivo mais significativo na comunidade, “Most Innovative JSR”, que reconhece o líder e grupo de especialistas da JSR mais inovadora, e “Outstanding Spec Lead”, que reconhece a liderança de uma JSR.
Neste mês, o SouJava foi indicado para este prêmio na categoria “JCP Member/Participant of the Year”, devido à promoção da abertura e transparência no JCP, como pode ser observado no anúncio da indicação:
“For tirelessly promoting the JCP, JSRs, openness, transparency and our community at large (to say nothing of Bruno Souza’s marvelous cape!).”
Juntamente com o SouJava, nesta categoria, foram indicados: Mike DeNicola, IBM, London Java Community, Doug Lea.
Reiteramos o compromisso do SouJava com a transparência e abertura do JCP, como pode ser observado nos votos realizados pelo grupo na sua participação como membro do Comitê Executivo do JCP:
Os vencedores serão anunciados na noite do dia 4 de Outubro deste ano, a partir das 18h.
Anúncio da indicação no blog do JCP:
http://blogs.oracle.com/jcp/entry/jcp_annual_award_nominees_2011
Informações sobre indicados e vencedores das edições anteriores do JCP Program Awards:
http://jcp.org/en/press/news/awards/awards_main
O SouJava está no Facebook. Acompanhe o Twitter do SouJava.
No último dia 12, o SouJava participou de mais uma votação no JCP apoiando a JSR #348: Towards a new version of the Java Community Process. Esta JSR tem como objetivo definir uma nova versão do Java Community Process, alterando a versão anterior com o intuito de aumentar a transparência do processo, garantir ampla participação nas atividades referentes, aumentar a agilidade e melhorar a governança do processo.
O SouJava considera esta JSR, um passo importante na evolução do JCP, como pode ser observado nos comentários realizados pelo grupo no seu voto:
“O SouJava está satisfeito em como esta JSR foi conduzida, na aplicação e teste dos princípios de transparência que esta JSR esta promovendo. O processo resultante será um um passo importante na reformulação contínua do JCP”.
Você pode conferir os votos dos demais participantes em JSR #348: Towards a new version of the Java Community Process – Public Review Ballot.
O SouJava está no Facebook. Acompanhe o Twitter do SouJava, e participe da discussão com a hashtag #SJJCP.
No início desta semana, dia 15/08/2011, o SouJava participou de mais uma votação no JCP apoiando a JSR #350: Java State Management. E continua trabalhando nas JSRs que propõem mudanças no JCP, para torná-lo mais aberto e participativo, como pode ser observado nos comentários realizados pelo grupo no seu voto:
“Gostaríamos de ver RI e TCK com licenças mais abertas, especialmente considerando que esta proposta pretende ser entregue juntamente com o implementação de referência do JavaEE. Esperamos também que esta JSR irá seguir as orientações da JSR-348 na transparência e envolvimento da comunidade, visto que são objetivos desta especificação.”
Você pode conferir os votos dos demais participantes em JSR #350: Java State Management – JSR Review Ballot.
O SouJava está no Facebook. Acompanhe o Twitter do SouJava, e participe da discussão com a hashtag #SJJCP.
No último dia 18 o SouJava apoiou as JSRs que definem a nova versão da plataforma Java, o Java 7 (JSR 336: JavaTM SE 7 Release Contents, JSR 203: More New I/O APIs for the JavaTM Platform (“NIO.2″), JSR 292: Supporting Dynamically Typed Languages on the JavaTM Platform e JSR 334: Small Enhancements to the JavaTM Programming Language, e votou favorável em todas elas. Mas o grupo tem preocupações com o futuro do JCP, e é por isso que participamos do processo e do seu comitê executivo, e estamos trabalhando nas JSRs que propõem mudanças no JCP, para torná-lo mais aberto e participativo.
Vejam abaixo os comentários feitos pelo grupo no seu voto.
JSR 336: JavaTM SE 7 Release Contents
“SouJava vota sim nesta JSR com base em seus méritos técnicos. Compreendemos e apoiamos as queixas de outros membros do Comitê Executivo e de muitos outros da comunidade Java em questões de licenciamento. Nossa leitura é que este é um momento de transição, no qual Java precisa avançar tecnicamente, e a respeito disto, nossos membros estão satisfeitos com a evolução da tecnologia. Mas estamos descontentes com os termos de licenciamento nesta JSR. Discriminando implementações de código aberto, eles obscurecem o trabalho que está sendo feito dentro deste processo, e levantam dúvidas quanto à abertura dos padrões resultantes. Isso é prejudicial para todo o ecossistema Java. Neste ponto, estamos dispostos a aceitar o que nós vemos como um passo atrás temporário no JCP. Mas a nossa principal diretiva é trabalhar para corrigir esses problemas, de modo que a próxima versão do Java pode ser tanto um passo a frente tecnicamente, quanto um passo em frente para tornar os padrões JCP mais abertos, inclusivos, transparentes e justos.”
JSR 292: Supporting Dynamically Typed Languages on the JavaTM Platform
“SouJava vota sim nesta JSR. Nós também gostaríamos de parabenizar a equipe que realizou esta importante mudança na JVM, que irá promover o relacionamento entre a comunidade Java e outra comunidades de desenvolvimento. Estamos ansiosos com as possibilidades criadas por essa JSR.”
Páginas (em inglês) com todos os votos:
Acompanhe o Twitter do SouJava, e participe da discussão com a hashtag #SJJCP.
