I'm excited to announce that plans for a top-level JSR for the Unified EL are underway. It's likely that Kin-man Chung will be filing a JSR in the near future. But we aren't waiting to get the discussion started. Kin-man has started the open el-next mailinglist (el-next@uel.dev.java.net), where we will begin itemizing priorities and designing features. We'll then convert the requests into issue reports as they are solidified.
As you may know, the Unified EL is currently trapped inside of the JavaServer Pages 2.1 specification: JSR-245. While steps have been taken to free the dependency on JSP, the language still has a distinctive JSP spin. The fact remains that the EL simply cannot become a first-class citizen that works across the Java EE platform without graduating to its own JSR.
In an email, Kin-man defined the goal for the Unified EL JSR:
The goal for the JSR is to make EL a first-class citizen that is easy to use, both inside and outside of Java EE.
Red Hat's focus will be to make sure that the JSR is developed in the open and that as many of the feature requests we have or have heard from our community are incorporated into the specification. Those enhancements can be found on the EL wishlist wiki page.
Follow along with the mailinglist archives and watch this space for more details. You can request to join the uel project if you want to get involved.
This aims at merging JSP EL and JSF EL, does it? Are there plans to merge Swing Beans Binding EL as well?
What does this mean, that there will be a standard API for resolving EL expressions? So one can use EL where ever they might find useful; Like for creating a Loggers that can take EL expressions or an EntityManager that can execute JPQL queries with EL expressions in them (like what seam offers)?
That's a very good news.
Dan, at Devoxx during the JSF BOF we talked about a seperate JSR to define page navigation such as Spring Web FLow or Seam Page Flow. Any news about this ?
That's good news.
we need unit testing frmwk, incremental hot reloading of all classes including EJBs (e.g. JRebel 3), and build system (e.g. Ant or Maven, etc.) standardized in JSRs as well...
We need good and free implementations for all those but I don't see the need for JSRs any more than we need a JSR for an IDE. Good implementations will become de facto standards. JSR:ing any of those would lead to stagnation in innovation.
Ok, so maybe that's why there is no JSR based directly on Spring? Having options for implementations including RI is good, no?
Hibernate was essentially JSR'd into JPA, no? Well JPA 1.0 was a subset but basically it was based on Hibernate.
I don't see the connection in your examples. The discussion was about tooling and stuff outside of the core language or of a problem domain to be solved with the Java language.
As usual, Arbi, you fail to appreciate the difference between APIs which application code depends upon and cannot execute without, and development-time tooling which application code does not depend upon. We've explained the difference to you several times before, so let's not reopen the totally off-topic discussion here.
Abslutely. But not just a standard API for resolving. Also a simple and standard API for bootstrapping, which is really the most tedious, tricky and fragile part of EL today.
Actually, I do believe we would benefit from an integration testing framework in the platform. Frankly, any platform without one is incomplete. That's why we are working on Arquillian. Perhaps it can evolve into a JSR one day. Who knows.