Como parte do conjunto de releases do Eclipse Juno, foi acrescentado o novo projeto Code Recommenders, cujo objetivo é ajustar e filtrar o conjunto de sugestões fornecidas ao sugerir código. Por padrão, o Eclipse mostra uma lista de métodos ou atributos públicos em ordem alfabética. No entanto, quando se está codificando com uma API pouco familiar, ou que possua muitos métodos sobrecarregados, nem sempre fica claro qual deve ser chamado.
O Code Recommenders possui um banco de dados de exemplos de código previamente utilizados, juntamente com a frequência das chamadas dos métodos. A ferramenta usa essas informações para priorizar qual método ou outro elemento deve ser sugerido. Se, por exemplo, a maioria dos construtores Date não usar argumentos (ou apenas um argumento long), então essas duas opções serão apresentadas primeiro e as outras serão filtradas e eliminadas. Além disso, a sugestão pode usar informações sensíveis ao contexto. Se o desenvolvedor estiver completando uma chamada de método em timezoneOffset=date.get, o método getTimezoneOffset() será exibido como a primeira opção.
O projeto Recommenders disponibiliza também uma lista de trechos de código sensíveis ao contexto, que pode ser criada manualmente ou inferida a partir de exemplos de código já existentes. Assim como outros templates para Java (como main ou syserr), esses trechos podem ser usados para implementar código de forma mais rápida.
O InfoQ ouviu Marcel Bruch, criador do projeto Recommenders:
InfoQ: O que motivou a criação do projeto?
Marcel Bruch: O Code Recommenders começou como um projeto de pesquisa na Universidade de Tecnologia de Darmstadt, na Alemanha, há cerca de três anos, mas suas raízes remontam a 2006. Nessa época, comecei a desenvolver os meus primeiros plugins para o Eclipse, além de ler os fontes de outros plugins para aprender as APIs do Eclipse. Ao mesmo tempo, a "mineração" de código-fonte era bem popular na comunidade científica. Como base para meu doutorado, decidi aplicar machine learning em código-fonte para auxiliar desenvolvedores (inclusive eu) a aprenderem como utilizar uma API.
Em 2009, publiquei a primeira versão do "Recommenders Intelligent Code Completion" no Eclipse Plugin Central (atual Eclipse Marketplace) e o apresentei no Eclipse DemoCamp. O projeto tinha muitas limitações e ainda era pouco utilizável, mas, depois de muitos acontecimentos, acabou se tornando um projeto do Eclipse, em janeiro de 2011.
O que me fez começar o Code Recommenders no Eclipse foi a ideia de criar algo que tivesse o poder de mudar a forma como desenvolvemos software, além do feedback positivo que recebi de algumas pessoas do Eclipse no momento certo.
InfoQ: Que tipos de recomendações faz o plugin?
MB: Na versão 1.0, o Code Recommenders sugere os prováveis métodos que o desenvolvedor chamaria em um objeto, ou quais métodos redefinir (override) ao se estender uma classe base de um framework. Auxilia também ao obter uma instância de um certo tipo com base na localização atual no código.
Essencialmente, o plugin ajuda no aprendizado de novas APIs e previne erros. Se o desenvolvedor já é perito na API, o plugin o tornará muito mais rápido, pois já sabe o que se deseja antes mesmo de pensar sobre o assunto.
E toda essa informação é fortemente integrada à funcionalidade de complementação de código do Eclipse JDT, bem como a uma visualização Javadoc Estendida, que resume todas as recomendações em um só lugar.
InfoQ: De onde vêm os dados usados para gerar as recomendações?
MB: O Code Recommenders baseia o seu aprendizado de recomendações em análises feitas no código-fonte de aplicações existentes, que usaram uma determinada API com sucesso. Para o Recommenders 1.0, os dados são obtidos do repositório integrado do Eclipse Juno, que consiste de 72 projetos e mais de 50 milhões de linhas de código.
Atualmente o projeto suporta muitas APIs do Eclipse e suporta parcialmente a biblioteca padrão do Java: os principais pacotes em java.* e alguns subpacotes de javax.*. Como os modelos de recomendação foram gerados somente a partir do código base dos projetos do Eclipse Juno, pacotes como o java.awt ou javax.swing ainda não são suportados, pois não haviam dados disponíveis para eles no momento da geração.
Para lançamentos futuros, estamos à procura de fontes de dados mais abrangentes, com a intenção de estender o escopo do Recommenders, para que haja suporte às bibliotecas frequentemente utilizadas, como a Apache Commons. Outra coisa que queremos suportar é a Plataforma Android, pois é muito parecida com o Java e muito popular, até mesmo para desenvolvedores de software semiprofissionais, que tornam-se candidatos perfeitos a usarem o Code Recommenders.
Mas fornecer suporte aos extensos ecossistemas do Java e do Android exige muitos dados. Estamos discutindo com alguns mantenedores de grandes repositórios de software, para que tenhamos acesso a seus enormes conjuntos de aplicações de exemplo para Android e Java. Nenhuma decisão foi tomada ainda, mas espero que achem o Recommenders convincente o bastante para apoiar o projeto no futuro próximo.
InfoQ: O Code Recommenders permite que se trabalhe com APIs customizadas ou que não conhece?
MB: O Code Recommenders pode aprender os padrões de uso de qualquer API Java, inclusive as feitas sob medida. A equipe do Code Recommenders do Eclipse trabalha atualmente no kit de desenvolvimento do Recommenders, que permitirá aos desenvolvedores criar assistentes de recomendações para suas próprias APIs, diretamente da área de trabalho do Eclipse.
No entanto, percebemos que construir assistentes de recomendações de alta qualidade não é simples. Isso se torna complicado quando se trata de um Big Data combinado com machine learning de grande escala e a análises de código estático. Decidimos então oferecer, no futuro próximo, serviços comerciais para auxiliar as empresas a fazerem o Code Recommenders trabalhar com suas APIs.
InfoQ: A lista de sugestões vem de uma análise de frequência de uso dos clientes?
MB: Sim, mas considerar somente a frequência com que cada método é usado no código do cliente não ajudaria muito. Por exemplo, considere um mecanismo de autocomplementação de código que sugerisse sempre a chamada setText() em um componente de texto. Isso faz mais sentido quando se trabalha em um método como, digamos, Dialog.createContents(), mas não faz sentido em Dialog.close(). Nesse caso, somente uma chamada a text.getText() faz sentido, e provavelmente é o que o desenvolvedor deseja: ler o que o usuário digitou em um componente textual.
Um mecanismo inteligente de complementação de código deve considerar essas questões, e é o que o Recommenders faz. Para completar chamadas de forma inteligente, por exemplo, rastreia-se em que lugares um objeto é usado, como o objeto foi definido, e quais dos seus métodos foram invocados até o momento, para que sejam feitas as recomendações mais adequadas e prováveis.
O modelo usado está sendo estendido para um assistente de recomendações mais avançado, que também considera informações como: quais outros objetos são visíveis no contexto atual da complementação, como foram usados até o momento etc. Nos bastidores há o trabalho das Redes Bayesianas, que efetuam todos os cálculos possíveis em alguns milissegundos.
InfoQ: Somente o Java é suportado? Há planos para outras linguagens?
MB: Sim, somente o Java é suportado atualmente. mas estamos investigando formas de levar o Code Recommenders para a família de linguagens C (C, C++ e C#) e até mesmo para as linguagens dinâmicas. Fica tudo mais difícil de prever quando não se tem a segurança de um sistema de tipos, mas temos algumas ideias sobre como suportar linguagens como JavaScript de modo semelhante. Mas para falar a verdade... temos um longo caminho a trilhar para que outras linguagens sejam suportadas. Podemos gastar todo o nosso tempo na melhoria do Code Recommender para Java, e fornecer o suporte a outras linguagens exigiria algum investimento externo e mais recursos da equipe para que isso aconteça o mais breve possível.
InfoQ: Quais são os próximos passos para o Code Recommenders?
MB: Em primeiro lugar, continuar o desenvolvimento do assistente inteligente de complementação de código, adicionando novos argumentos ao "método adivinhador". Desenvolvedores familiarizados com o SWT conhecem os problemas que os seus style bits causam, por exemplo, quando se registra um listener, ou quando um componente de texto é criado. Mas saber quais constantes ou mesmo quais objetos podem ser passados em uma chamada de método, pode ser aprendido quase que do mesmo modo que se aprendem quais métodos podem ser chamados, como demonstrado recentemente por Cheng Zhang, da Universidade de Shanghai, na China. Cheng está trabalhando na integração da sua ferramenta ao Code Recommenders do Eclipse.
Outra área em que estamos tendo progresso é na de mineração de trechos de código a partir de códigos de exemplo. Todos os desenvolvedores conhecem a funcionalidade de complementar código baseado em templates de suas IDEs, que oferecem trechos de código para iterar em um array, efetuar a conversão de tipos etc. Mas precisamos muito mais de trechos de código que demonstrem como se usa um objeto e também como isso pode ser feito em combinação com outros objetos.
Os templates para o SWT do Eclipse fornecem alguns desses exemplos, que mostram como criar instâncias e configurar widgets do SWT. No entanto, criar os templates é uma tarefa dispendiosa; portanto há bem pouco destes templates disponíveis. A equipe do Code Recommenders tem trabalhado em ferramentas que mineram padrões de codificação encontrados, com frequência, em códigos de exemplo e integram os padrões obtidos neste processo ao seu IDE. O mecanismo de complementação de código Snipmatch, desenvolvido por Dough Wightman da Universidade de Queens, no Canadá e Cheng Chen, através do programa Summer of Code do Google, fará a integração dos fragmentos minerados, resultando em um novo tipo de templates de complementação.
Outra área de progresso é no mecanismo de busca em stack traces. Usuários do Maven já estão familiarizados com a ideia. Sempre que um build do Maven falha com uma exceção, a última linha impressa sugere ao usuário uma visita à página wiki, que tem grandes chances de descrever a causa da exceção. Infelizmente, em sua maioria, estas páginas estão vazias. A ideia, no entanto, é ótima.
Stack traces contêm muito mais informações do que se imagina, e aproveitar as informações implícitas disponíveis em tempo de execução para encontrar recursos na web, que discutam ou solucionem o problema. Johannes Lerch, da zniversidade Técnica de Darmstadt, está trabalhando neste projeto. Estou curioso para ver quanto tempo vamos poupar no futuro com a solução de problemas que já foram solucionados por outros.
Por último, estamos trabalhando em um mecanismo de busca de trechos de código de exemplo, que encontra códigos relacionados à tarefa que o desenvolvedor está realizando.
Esses são os candidatos que pensamos para o Eclipse 4.3 (Kepler), que será disponibilizado em 2013. Mas, nos bastidores, estamos trabalhando em algo maior, nossa visão para o IDE 2.0.
Pode-se ver mais sobre o Code Recommenders na página do projeto, e baixá-lo como parte dos pacotes do Juno; ou fazer a instalação diretamente do Eclipse Marketplace.