A Oracle anunciou recentemente uma JSR para o MVC 1.0. A JSR 371 foi motivada pelos resultados da pesquisa sobre o Java EE 8, abordada em março desse ano pelo InfoQ.com. 61% dos pesquisados apoiam a ideia de fornecer suporte para um framework MVC baseado em ação, lado a lado do JSF. Somente 26% sentem que existe um framework que pode fazer o serviço, e 42% mencionaram o Spring MVC. O AngularJS e o Play Framework, que executam com base em regras também foram comumente mencionados.
A especificação MVC 1.0 define que os frameworks web de Interface de Usuário (User Interface - UI) podem ser categorizados como baseados em ação ou baseados em componente, e este se enquadra na categoria baseado em ação. Isso não é uma substituição ao JSF, é simplesmente uma abordagem diferente para construir aplicações web da plataforma Java EE. Com isso é possível que o JAX-RS possa ser aproveitado como o controlador, e uma nova linguagem de layout está fora do escopo.
O anúncio foi recebido com suporte pela Red Hat, ambos na lista de emails do java.net e em publicação no blog do Java MVC 1.0. O engenheiro da Red Hat e parceiro Bill Burke manifestaram seu descontentamento.
O blog da comunidade do GlassFish também escreveu sobre a JSR MVC 1.0. Foi notado que os líderes da JSR têm se destacado na comunidade Java EE: Santiago Pericas-Geertsen (o co-líder da especificação JAX-RS) e Manfred Riem (o co-líder da especificação JSF).
Ed Burns, o outro co-líder da especificação JSF, escreveu um artigo "Por que outro MVC?" para responder algumas questões. Burns disse que o Jersey MVC irá "certamente influenciar seu design" e mostra um exemplo de como um controlador deve ser:
@Path("/") @Singleton @Template @Produces("text/html;qs=5") @XmlRootElement @XmlAccessorType(XmlAccessType.FIELD) public class Bookstore { private final Map<String>, <Item> items = new TreeMap<String, <Item>(); private String name; public Bookstore() { setName("Czech Bookstore"); getItems().put("1", new Book("Svejk", "Jaroslav Hasek")); getItems().put("2", new Book("Krakatit", "Karel Capek")); getItems().put("3", new CD("Ma Vlast 1", "Bedrich Smetana", new Track[]{ new Track("Vysehrad",180), new Track("Vltava",172), new Track("Sarka",32)})); } @Path("items/{itemid}/") public Item getItem(@PathParam("itemid") String itemid) { Item i = getItems().get(itemid); if (i == null) { throw new NotFoundException(Response .status(Response.Status.NOT_FOUND) .entity("Item, " + itemid + ", is not found") .build()); } return i; } @GET @Produces({MediaType.APPLICATION_XML, MediaType.TEXT_XML, MediaType.APPLICATION_JSON}) public Bookstore getXml() { return this; } public long getSystemTime() { return System.currentTimeMillis(); } public Map<String>, <Item> getItems() { return items; } public String getName() { return name; } public void setName(String name) { this.name = name; } }
Burns escreveu que essa abordagem provavelmente será escolhida por aqueles que querem um grande nível de controle sobre a requisição / resposta.
Os web designers podem se favorecer nessa abordagem porque eles veem a abstração fornecida por um MVC orientado a componentes como uma forma de realmente obter o controle dos seus próprios HTML/CSS/JS. Finalmente, essa abordagem é ótima para o REST por causa de sua associação com a semântica do HTTP.
Os feedbacks no Reddit foram bem diversificados. Muitos não querem essa JSR porque haverá dois frameworks da UI Web no Java EE. Outros mencionaram que isso não é um problema no mundo Microsoft, com o ASP.NET Webforms e ASP.NET MVC. O usuário do Redditor johnwaterwood fez um comentário interessante:
O detalhe mais irônico: votei para o suporte ao MVC/Action na pesquisa pensando sobre o suporte de ação do JSF. Mas agora usam o meu voto como uma justificativa de que a comunidade quer que o MVC do Spring venha para o Java EE.
Baseado na quantidade de fãs do Java EE criticando o movimento e dos desenvolvedores web Java que querem essa JSR, parece que ainda haverá bastante discussão. Será que o framework MVC 1.0 será bom o suficiente para satisfazer as exigências dos entusiastas orientados a ação? Há muitos fãs do Spring MVC, Grails, Play 2 e Struts 2 que estão fora dessa lista (de acordo a projeção das ferramentas Java e painel de tecnologias da RebelLabs para 2014). Resta apenas ver se os desenvolvedores desses frameworks ajudaram a fazer do MVC 1.0 o melhor framework web orientado a ação para os desenvolvedores Java.
A agenda antecipada dessa JSR inicia agora nesse trimestre e termina em dois anos:
Terceiro trimestre de 2014 - formação do grupo de especialistas;
Primeiro trimestre de 2015 versão inicial da especificação;
Terceiro trimestre de 2015 - revisão pública
Primeiro trimestre de 2016 - proposta da versão final
Terceiro trimestre de 2016 - versão final
O site do projeto da JSR, https://mvc-spec.java.net, ainda não estava ativo quando esta notícia foi publicada.
JSR apartada do JAX-RS
by Wryel Covo,
Re: JSR apartada do JAX-RS
by Ivan Salvadori,
JSR apartada do JAX-RS
by Wryel Covo,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Não vejo com bom olhos aparentemente extender o JAX-RS para dar suporte à MVC. Uma coisa é REST, outra coisa é um "padrão arquiteturial" (talvez usaram JAX-RS só para dar uma visão mais ampla).
Conheço medianamente Spring MVC e acho que o básico dele já faz um ótimo trabalho (o suporte a anotações é bem direto). O pouco que brinquei com play achei legal também (mas as rotas, pelo menos na época em que vi, ficavam em um arquivo .properties, ai entra a questão de "gosto"). O Guice da Google tem um módulo web que você consegue associar padrões definidos de url para Servlets atenderem (é bem legal para aplicações pequenas e que você não quer levar um "mundo" de dependências).
Como essa JSR me interessa muito, acho que eu vou dar uma participada na lista de discução.
Re: JSR apartada do JAX-RS
by Ivan Salvadori,
Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!
Realmente, concordo com com o comentário de Wryel Covo.
Parece um pouco (muito) estranho estender JAX-RS para suporte MVC.
Quem escolhe JAX-RS já optou por não utilizar MVC (server+client).