A Fundação Eclipse anunciou o Eclipse Juno M5, versão com as principais funcionalidades da futura versão do IDE Eclipse. Entre as novidades, a release implementa a análise de trechos de código com referências nula (null pointer) e um novo mecanismo para detectar vazamento de recursos no código (no Java 6 através do try-catch convencional e no Java 7 com o novo try-with-resources).
Essa é a primeira release do Eclipse IDE baseada no E4, a nova arquitetura da plataforma Eclipse, que representa uma mudança significativa na infraestrutura de componentes visuais do Eclipse. A partir dessa versão os modelos do EMF (Eclipse Modeling Framework) são criados de forma declarativa, sem a necessidade de código para representar a interface gráfica. Esses modelos são introspectivos e podem ser modificados em tempo de execução, fazendo com que qualquer mudança seja renderizada imediamente na janela. Outra nova característica é um mecanismo automático para persistir o estado da tela quando necessário.
Uma das principais vantagens de modelagem declarativa para a interface gráfica é, como acontece no HTML, a possibilidade de separar a estrutura da interface com o usuário, da sua apresentação. Isso possibilita o uso de CSS para definir o estilo visual da interface, de forma isolada do código escrito para tratar eventos dos componentes, por exemplo.
Outra melhoria trazida pelo E4 é o uso de injeção de dependências para a aquisição de serviços utilizados pela plataforma. Anteriormente a plataforma utilizava assessores estáticos para recuperar os serviços utilizados com mais frequência (por exemplo, SelectionService que fornece informações de um componente selecionado pelo usuário para outros módulos do Eclipse). Muitos desses serviços estão disponíveis desde o lançamento da plataforma Eclipse, mas a transição para OSGI (que ocorreu na versão 3) não modificou os serviços. Agora, com o E4, esses serviços foram expostos como serviços OSGI, e podem ser consumidos tanto pelo Eclipse quanto por clientes OSGI.
Para facilitar a recuperação dos serviços do "singleton" (de Workbench e o serviço de Logging, por exemplo), os plugins do Eclipse podem declarar um "ponto de injeção". Este ponto será acionado pelo E4 durante a inicialização do plugin, para identificar e resolver dependências, através dos serviços disponíveis na plataforma. Esta estratégia de componentização é bem similar ao modelo adotado pelo Spring; a diferença é que a própria plataforma faz o papel do Application Context sem a necessidade de configurações adicionais.
Considerando as grandes mudanças realizadas nos mecanismos de localização de serviços entre as versões antigas e atuais da plataforma, foi implementada uma camada de compatibilidade, que traz um conjunto APIs que mantêm os mesmos contratos utilizados pelos plugins nas plataformas antigas. (Note que essas APIs substituem a implementação anterior, o que pode ocasionar novos bugs e comportamentos não existentes em anteriormente.)
A transição para a plataforma E4 tem ocorrido de forma gradual. Lançada pela primeira vez como SDK 4.0, depois do Eclipse 3.6 Helios. Uma nova versão da plataforma, a SJD 4.1, foi lançada após o Eclipse Indigo 3.7. A expectativa é que com o lançamento do Eclipse Juno, os usuários poderão fazer a transição para a plataforma 4.2 (embora exista a versão 3.8 disponível).
O time de desenvolvimento da plataforma Eclipse é formado em sua maioria por funcionários e ex-funcionários da IBM, a empresa que criou o projeto. São poucos os participantes externos. Segundo um email de Mike Wilson (um dos líderes do Projeto Eclipse), atualmente existem três desenvolvedores para o projeto, o que levanta preocupações se seria possível entregar a versão 4.2 da plataforma em tempo para inclusão no Juno. Wilson argumenta que um atraso seria "catastrófico" para a comunidade:
Pode-se argumentar que seria melhor simplesmente lançar o Juno com a plataforma 3.8 e seguir em frente com a versão 4.x, para inclusão numa versão posterior. Mas acredito que isso seria catastrófico. O lançamento simultâneo será a base para ambos os termos de suporte da fundação: Eclipse Long Term Support e Very Long Term Support. Levando em consideração a maturidade global do Eclipse e as necessidades de várias grandes organizações que participam do projeto, vejo o Juno como uma release extremamente importante.
Se não entregarmos a plataforma 4.2 juntamente com o Juno, uma enorme parte da comunidade não será capaz de tirar proveito de novas funcionalidades da plataforma. Mais importante: a comunidade estaria desenvolvendo sobre código que será substituído, o que significa que não seria possível para a plataforma se adaptar à evolução e às novas necessidades de aplicações modernas. Isso, mais que qualquer outra coisa, colocaria em risco o futuro do Eclipse no desktop.
Mike Wilson reconhece as preocupações em relação ao patrocínio/controle de uma única empresa (a IBM) para o projeto Eclipse, pelo menos em termos de committers:
Está claro para mim que o time da Plataforma Eclipse, na verdade o projeto Eclipse como um todo, precisa de mais committers de fora da IBM. E vou além: precisamos de pessoas ativas, trabalhando no SDK para o bem da comunidade em geral. Está claro que a quantidade atual de committers no projeto é muito pequena para suportar a demanda de trabalhos na evolução da plataforma.
Wayne Beaton, evangelista da Fundação Eclipse, acredita que a neutralidade de um fornecedor em um projeto aberto não é apenas essencial, mas sim exigido pelo regimento do Eclipse:
A tecnologia Eclipse constitui uma plataforma aberta e independente de fornecedor, que oferece ferramentas de referência e extensíveis (a "Plataforma Eclipse").
Por fim, a Fundação Eclipse decidiu que a versão de 2013 será chamada de Eclipse Keplar. O Eclipse Keplar será construído sobre a plataforma 4.3, mas os usuários mais ansiosos terão de aguardar até meados de 2013 para o lançamento dessa versão.