Netbeans growing stronger

During several years I’ve been a pretty happy Eclipse user, rarely feeling the need to use anything else. We know there are plugins for many many things, and a lot of development tools are Eclipse-based right now. The editor is awesome, and so are the refactoring tools. The support for web app development is also very nice. Eclipse supports a wide set of frameworks and technologies, and it’s not only aimed at Java development.

Why would someone even look at anything else, having such a great tool? Well, it turns out that our field is evolving really fast, and it’s very hard to follow this current pace, even for the most dedicated and passionate ones. Currently there are several technologies evolving very fast, and they are meaningful to a lot of enterprise developers. The rise of the JVM’s dynamic languages is crystal clear. Strong is also the growth of RESTFul web services. I’m personally very interested in both fields.

I’m currently using REST (lately with Jersey) for a lot of integrations between applications. The power it gives me is really nice, and I’m improving my developments each new month. I have also studied Groovy/Grails recently and really liked it. I wanna try JRuby on Rails sometime in the next weeks, to see what it offers and check how it compares to Grails. If you’re a Java enterprise developer, I’m sure you’re following the growth of these nitty things.

But where does Netbeans enter this talk? Well, Netbeans is doing a great job supporting these new technologies, and it’s way ahead of Eclipse in this field right now. Have you seen how easily you can develop RESTFul web services with Netbeans 6.1? Jersey support is great, very productive. The support for JRuby on Rails and Grails is also present, in a much more advanced state than Eclipse’s. Netbeans is doing a much better job than Eclipse regarding Web Services and JVM languages right now.

Swing development in Netbeans is very nice since version 5.0 (with the release of Matisse), and developing for mobile devices is also easier in Netbeans. Currently I don’t develop swing nor mobile applications, so this doesn’t really affect me.

However, I develop many RESTFul web services. And I wanna use more and more the JVM’s dynamic languages. Ignoring Netbeans is not a clever idea right now.

I still find Eclipse’s interface and editor much better than Netbeans’s. I also know a lot of Eclipse’s shortcuts and know very few in Netbeans. SWT is also faster than Swing, so Eclipse is faster than Netbeans. But considering what I said, I’m leaning towards the use of both IDEs at the same time. Since our machines are now much better equipped with RAM, I can have them open at the same time and also a couple of servers, with no memory shortage.

My Eclipse days are definitely not over, but now he’s gonna divide my attention with Netbeans I hope I can become as productive with Netbeans as I am with Eclipse, even if it takes a few weeks. My first wish would be the Eclipse’s Quick Fix (Ctrl + 1) avaiable in Netbeans. Even without it, I’m sure my usage of Netbeans will certainly grow, and think this competition between the IDEs is very good for us. Let Eclipse Ganymede come!

Grails - ótima ferramenta para alguns projetos

Toda semana eu e o Silvano discutimos vários aspectos das nossas aplicações. Como melhorar algumas delas, novos componentes que podem trazer ganhos interessantes, mudanças de arquitetura, etc. Os principais objetivos são: trazer mais qualidade para os projetos e produtividade para a equipe.

Alguns meses atrás estávamos falando com freqüência sobre frameworks web. A maioria das aplicações na Globo ainda usa Struts 1.x. O Struts 1 foi por muitos anos o framework web padrão Java. Ele trouxe muitos ganhos interessantes, comparando com o desenvolvimento usando apenas Servlets + JSP.

Um ponto “fraco” do Struts 1 é que ele não tem nenhum suporte a componentes visuais. Toda a parte visual das aplicações fica por conta dos desenvolvedores, assim como os recursos “Web 2.0″. O problema é que desenvolver esta parte visual de forma customizada em todos os projetos é muito trabalhosa, não é produtiva. Com isso surgiram inúmeros frameworks mais modernos, com suporte visual muito mais rico, trazendo boa produtividade neste aspecto.

O fato é que com esta enorme gama de opções, não temos mais um framework que se destaque de forma absoluta sobre os outros. Temos várias opções para cada projeto. Entretanto, não dá para querer abraçar o mundo, então é comum que busquemos 1 ou 2 opções que nos atendam em quase todos os casos.

Na nossa equipe nós já temos uma aplicação com JSF, que na verdade foi concebida ano passado, antes da minha mudança de equipe. Eu estou usando o Wicket em um projeto pessoal e ainda estou aprendendo o framework, ainda não o domino a ponto de usá-lo de forma produtiva. Com alguma freqüência nós discutimos sobre estes 2 frameworks, e eu ainda tenho a opinião que descrevi anteriormente.

Neste escopo das discussões sobre JSF vs Wicket, também falamos algumas vezes sobre Rails e Grails. Algumas semanas atrás eu e o Silvano começamos a estudar Grails, e fizemos pequenas aplicações de exemplo. Eu já li inteiro este livro de Grails disponível no InfoQ. Ele estava aqui na minha lista de “Livros que quero ler quando tiver tempo”, mas já o movi para a lista de livros que li

Eu estou gostando bastante do Grails, pois ele é extremamente produtivo para aplicações nas quais eu acho que ele faz sentido. Você consegue em 2 dias desenvolver aplicações que provavelmente você demoraria 1 semana ou mais com frameworks Java tradicionais. Eu ainda não o utilizei o suficiente para saber os limites de uso do mesmo. Provavelmente para projetos com requisitos mais críticos de carga e customização das interfaces, ele já não será uma opção tão boa assim. Entretanto, em aplicações internas, com carga limitada e sem grandes necessidades de customização visual, ele é perfeito.

O próximo passo para mim é tentar utilizá-lo em casos mais complexos. Estou pensando seriamente em utilizá-lo no @dvogado.com, um software para advogados que eu desenvolvo no meu tempo vago, mas que está congelado há alguns meses por falta de tempo. Quando eu conseguir um pouco mais de tempo vou tentar implementá-lo com o Grails, e acho que consigo fazer isso bem rapidamente. O Grails atenderia bem à minha proposta de distribuir um pacote completo com tudo que o usuário precisa, tornando o deployment o mais simples possível. Com o Grails eu utilizaria o Jetty + HSQL que ele traz por padrão, e precisaria adicionar apenas o JDK no pacote.

Uma discussão muito interessante também é a de Grails vs Ruby on Rails, mas isso fica para um outro post em breve

Java Magazine 56

Nos próximos dias chega às bancas a edição 56 da Java Magazine. Nesta edição saem 2 artigos meus sobre Web Services REST. Como vocês podem ver pela imagem, desta vez os editores me deram a honra de ser a capa da edição

Outra honra que tive no artigo maior foi a de contar com a excelente colaboração do Alexandre Bairos. Durante nossos trabalhos em cima deste artigo pudemos discutir com todos os detalhes as várias nuances dos serviços REST, com os quais já estamos trabalhando há alguns meses e estudamos já há um bom tempo.

O artigo maior é uma continuação dos artigos das edições 54 e 55. A proposta dele é pegar o exemplo dos serviços de leilão da edição 55 e implementar uma solução utilizando serviços REST.

A abordagem deste artigo foi implementar os serviços REST de forma que ficassem nítidos os principais aspectos do desenvolvimento desta linha de serviços. Tomamos a decisão de não incluir componentes sofisticados que pudessem tirar o foco do cerne do problema. Com isto, não incluímos componentes como o Jersey e o Apache Abdera, que por sua vez devem ter artigos na revista este ano.

O artigo pequeno é no formato “Quick Update” da revista. Nele eu falo sobre os principais projetos relacionados aos serviços REST e os principais acontecimentos nestes projetos. Esta linha de web services vem evoluindo bastante, e por trás disso estão muitos projetos interessantes.

Na minha humilde opinião o artigo maior desta edição é certamente o melhor dos artigos que já escrevi para a revista e acredito que ele pode contribuir como um bom ponto de partida no assunto. Este assunto é talvez o que mais me interessa atualmente, então caso vocês tenham opiniões, comentários ou críticas a fazer, estou aqui para trocar idéias

IBM investe US$ 10 mi no Postgresql. Mais consolidações à vista?

Essa semana fiquei sabendo pelo blog do Savio Rodrigues que a IBM investiu US$ 10 milhões no EnterpriseDB, uma derivação comercial do Postgresql, mas cujos desenvolvedores atuam no desenvolvimento do produto open source também.

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

Java Magazine 55

Caros amigos, nos próximos dias chega às bancas a edição 55 da Java Magazine. Nesta edição sai um artigo meu entitulado “Web services WS-*“.

Este artigo é uma continuação do artigo da edição 54, na qual fiz uma análise dos web services REST e web services WS-*. Na edição 54, o foco era mais teórico, discutindo várias questões relevantes da implementação de web services nas 2 linhas de desenvolvimento.

Neste artigo, o objetivo é partir de um problema real de arquitetura orientada a serviços, e então realizar a modelagem e implementação utilizando a pilha WS-*. O exemplo adotado para contextualizar o problema é o processo de leilão do Mercado Livre, mas num contexto de leilão com apenas 1 usuário adquirindo um determinado item. O desenvolvimento foi feito utilizando o Apache Axis 2, uma das opções mais populares para o desenvolvimento deste nicho em Java.

Na edição 56, esta série será complementada com outro artigo prático, que utiliza a abordagem REST para resolver o mesmo problema proposto para esta edição. O objetivo com estes 2 artigos práticos é utilizar um mesmo exemplo que seja de fácil visualização por parte dos leitores e então descrever os detalhes principais do desenvolvimento de web services utilizando a abordagem WS-* e a abordagem REST.

Espero que os leitores gostem destes artigos e torço para que eles possam contribuir com o entendimento do desenvolvimento de web services, e mais especificamente, a implementação em Java. Ao longo do ano escreverei mais artigos nesta área, então se você tiver interesse no assunto, certamente recomendo acompanhar as edições futuras da revista

Criando requisições HTTP através de proxies com o Commons HttpClient

Hoje eu tive que criar algumas requisições HTTP através de um proxy, numa integração que estou implementando. Minha aplicação precisa enviar solicitações HTTP a um servidor remoto, passando por um proxy, e eu uso o Commons HttpClient para montar estas requisições.

Como achei a documentação disso bem fraquinha no site do projeto, resolvi postar aqui um exemplo de código para facilitar quem possa precisar (e a mim mesmo no futuro). Este exemplo é um método de teste junit bem simples que monta uma requisição RESTful de cadastro de um novo usuário, especificando as configurações do proxy na API. Utilizei o XStream para fazer as manipulações XML. Segue o exemplo:

public void testCriacao() throws HttpException, IOException{
Usuario novoUsuario = new Usuario();
novoUsuario.setLogin(”fulano”);
novoUsuario.setSenha(”123456″);
novoUsuario.setNome(”Fulano”);
novoUsuario.setSobrenome(”da Silva”);
novoUsuario.setStatusConta(1);
novoUsuario.setTamanhoMailBox(6144);

HttpClient client = new HttpClient();
//servidor remoto que iremos acessar
HostConfiguration hostConfiguration = new HostConfiguration();
hostConfiguration.setHost(”www.domain.com”, 8080);
// proxy pelo qual precisamos passar
ProxyHost proxy = new ProxyHost(”10.10.10.10″, 9090);
hostConfiguration.setProxyHost(proxy);
client.setHostConfiguration(hostConfiguration);

PostMethod method = new PostMethod(”http://www.domain.com:8080/MailIntegration/usuario/”);
XStream xstream = new XStream();
xstream.alias(”usuario”, Usuario.class);
String usuarioXml = xstream.toXML(novoUsuario);
StringRequestEntity requestEntity = new StringRequestEntity(usuarioXml, “text/xml”, “UTF-8″);
method.setRequestEntity(requestEntity);
int statusCode = client.executeMethod(method);
assertEquals(201, statusCode);
Usuario usuarioCadastrado = (Usuario)xstream.fromXML(method.getResponseBodyAsStream());


Java annotations abuse

I know Java annotations are a very controversial subject, and there are lots of different opinions regarding them.

In a general manner, i like annotations. Annotations placed on classes and methods are nice, they help a lot without much damage. A good example of well used annotations in my opinion is the Java Persistence API. It reduces a lot of the code you’d need to write and doesn’t polute things too much.

However, placing annotations inside method arguments, such as in JSR-311 (first place where i saw it) starts to really mess things up. Here’s an example of the use they propose:

@UriTemplate("widgets")
public class WidgetList {
@HttpMethod
@UriTemplate(”offers”)
WidgetList getDiscounted() {…}

@UriTemplate(”{id}”)
Widget findWidget(@UriParam(”id”) String id) {
return lookupWidget(id);
}
}

The @UriParam is the one that really bothers me here. I’m sure it must serve a good purpose for the JSR, and it probably makes some stuff easier. However, it’s unquestionable that annotating this much starts to polute the code beyond the acceptable limits. In such a short piece of code we saw 5 annotations.

I’m not saying we should go back to XML files. I really prefer annotations over XML when they are used over classes and methods, much like JPA does it. However, as many other things, annotations can be misused, and in this JSR 311 example, i think they misuse them. I just hope this trend doesn’t get stronger, because i think Java would get uglier with this. Just keep the simple annotations please

Google Data API

I’m currently using Google Data API at work. This API offers RESTful interfaces for several Google services, such as Calendar, Picasa, You Tube, Blogger, Google Documents, among others. There are also client libraries for Java, C# and Python, but these are actually tools to facilitate, rather than new interfaces. All client libraries access the RESTful interfaces, so by all acounts the API is RESTful.

What I’d like to comment is how easy it was for me the to get up to speed with the API. There are several pages explaining the API’s features, the URIs, their use of HTTP method, return types, etc. Their design is pretty much compliant to all REST best practices (although they do use some query string parameters ocasionally). Being very familiar with this kind of web services, most of what I did was looking and saying: “Ok , this is how i expected it to be”. And after less than one hour I was ready to begin using the API properly.

Worth noting is that there were no “Interface Document” to look at. Not anything similar to WSDL or any other IDL. What was there was just a simple and RESTful API that was pretty easy to use after you knew what the resources were and which operations they support. Several pages describing their protocol and the XML entities they use were enough for me to know how I was supposed to integrate with a reasonable amount of their services.

I don’t even want of to think of how would it be if they had WS-*. Just to read the WSDL documents would take me more time than to read all their RESTful documentation. There would be a lot of operations and messages described in their WSDLs, and it’d be a massive reading to get the grasp of the API.

Fortunately Google (the most powerful web company) is embracing a RESTful design and it should probably take many other companies with it. They’re also supporting the use of Atom and Atom Publishing Protocol, so many nice things should keep coming. Apache Abdera is already integrating Google Feed Server code, and hopefully we’ll be able to use Abdera for most of Google’s services.

Very very nice! By the way, I took a good look in the source code of Google Data API and it’s very well implemented. They have a very interesting approach to manipulate feeds and entries. It makes it very easy to model a lot of stuff using just feeds and entries. It was an inspiring code inspection and I’m thankful Google also embraces open source These guys are good!

Jersey meets Abdera

Talvez os dois mais promissores projetos atualmente sendo desenvolvidos na área de web services Rest são o Apache Abdera e o Jersey. O Apache Abdera oferece uma API para manipulação de conteúdo no formato Atom, e é bastante útil para implementações baseadas no Atom Publishing Protocol. Já o Jersey é a implementação de referência da JSR-311, que mencionei num post recente aqui no blog.

Os 2 projetos são complementares, já que as funcionalidades de ambos não tem muitas interseções. Ontem o Marc Hadley, um dos principais desenvolvedores do Jersey postou sobre um desenvolvimento que ele está fazendo, usando o Jersey e o Abdera em um projeto de web services Restful. No post do Marc Hadley ele menciona que utilizou os recursos HTTP do Jersey (como mapeamento de URIs em classes e métodos e a capacidade de manipular diversos content-types) juntamente com as funcionalidades do Abdera de manipulação de recursos Atom.

Esta iniciativa foi muito bem recebida pelo James Snell e pelo Dan Diephouse (fundador do XFire), que são os principais desenvolvedores do Apache Abdera. O desenvolvimento destes dois projetos vem trazendo enorme amadurecimento aos web services REST e hoje já é possível desenvolver web services neste formato com grande produtividade e poder.

Claro que os projetos ainda estão em um estágio intermediário de desenvolvimento, mas é deles que virá a adoção mainstream com maturidade desta linha de serviços. Estou acompanhando continuamente o que está sendo feito nesta área, e o que já pude ver até agora é fascinante.

A propósito, os dois projetos são open source e os principais envolvidos fazem parte de empresas como a IBM, Sun, Mulesource, entre outras. O desenvolvimento de software open source é hoje em dia a principal forma de desenvolvimento da vanguarda da tecnologia mundial. As empresas já perceberam o sucesso do movimento e estão apoiando firmemente o mesmo. Não posso deixar de registrar minha profunda satisfação com isso.

JSR-311: Java API for RESTful Web Services

Eu estou atualmente implementando alguns web services Restful, e estou avaliando opções para alguns pedaços do desenvolvimento. Eu já sabia que existia uma JSR para web services REST, mas ainda não tinha lido a mesma.Agora há pouco li a JSR-311, que definirá padrões de implementação Java para uma API Rest, do lado do servidor. A parte de implementação de clientes será tratada em outra(s) JSR(s) .

Esta JSR é bastante interessante, e já pude ver nela o tratamento de coisas muito úteis. De principal destaque para mim está a abordagem de mapeamento de URIs em recursos e métodos e a questão do mapeamento de classes Java para dados com diversos content-types.

Em relação às URIs, há a definição de regras para mapear URIs em classes e métodos, instanciando as classes necessárias e invocando os métodos adequados. Suponha por exemplo uma requisicao HTTP PUT na URI /usuario/16728/produto/228/configuracao/. Em um protocolo definido por mim, isto representaria uma atualização nas configurações do Produto 228 para o Usuário 16728. Um ser humano consegue entender isso sem tantos problemas, mas uma implementação manual destes mapeamentos e o parsing dos parâmetros podem ser coisas bem trabalhosas. A JSR 311 utiliza várias annotations para conseguir definir o encadeamento de classes e métodos a partir da URI utilizada, e isto faz com que você consiga desenvolver em Java normalmente e ter as suas classes instanciadas e invocadas com URIs tão flexíveis quanto você queira. Muito bom ter isso como recurso, pois implementar na mão é bem trabalhoso.

Outra coisa muito interessante é a maneira de mapear classes Java para diversos content-types. Isso é algo fundamental para uma implementação Restful com bastante flexibilidade E possivelmente alta performance. A idéia por trás disso é que o servidor recebe uma requisição de um cliente e verifica quais são os content-types que o cliente aceita. Com base nestas informações, o servidor escolhe a forma que irá utilizar para transmitir os dados.

Suponha por exemplo que uma aplicação PHP está se comunicando com seu servidor, e ele lhe informa que aceita os content-types text/plain, text/xml e application/json. O servidor pode escolher qual formato utilizar para o envio e possivelmente o envio com formato json facilita bastante a aplicação PHP. Este mesmo servidor pode receber requisições de uma outra aplicação Java, que preferencialmente receberá do seu servidor um stream binário, que terá a melhor performance de todas as opções.

O uso desta abordagem dos mapeamentos em content-types permite que sua aplicação tenha ao mesmo tempo alta interoperabilidade e alta performance. Você conseguirá se comunicar com várias plataformas e aplicações diferentes, e continuará tendo a opção de alta performance, caso seja uma aplicação da mesma plataforma. Você não consegue isso com web services WS-*. Eles não têm tamanha flexibilidade.

O meu próximo passo agora será analisar com detalhes o Jersey, a implementação de referência desta JSR. A especificação em si ainda está um tanto crua, pois ainda é um early draft. Já pude ver vários pontos interessantes, mas a definição ainda está sujeita a muitas modificações. Vou avaliar agora o que o Jersey já oferece e torcer para que ele já tenha componentes fáceis de usar e flexíveis. A proposta dele é excelente, vamos ver se a implementação consegue oferecer estes recursos sem amarrar muito as decisões de projeto.