Should the community take over JSF.next or not?

-
JSF aka JavaServer Faces is a component based MVC framework that's part of Java EE and is one of the oldest Java MVC frameworks that's still supported and actively used (version 1.0 was released in 2004).

Over time, Java EE itself has grown considerably and as such the resources required to maintain and evolve Java EE have grown as well. Now Oracle has indicated at several occasions that it just doesn't have the resources required for this, and for most constituent specs of Java EE it can do at most small updates, but in other cases can't do any updates at all.

In order to lessen this immense burden on Oracle somewhat, the community has largely taken over for JSF 2.3 and Java EE Security API 1.0. The following graph (taken from a presentation by JSF spec lead Ed Burns) gives an indication:

The question is how to continue for JSF.next?

Since the community has largely taken over JSF already, should this perhaps be made more formal by actually letting the community (individual, foundation, or even representative small company) take the lead in developing the next version of JSF? In such scenario, the existing JSF versions (2.3 and before) and their respective TCKs would stay with Oracle, but JSF.next (i.e. JSF 2.4 or 3.0) would be fully specified, implemented and released by the community (OmniFaces in particular, with possibly the help of others).

Is a large and important spec such as JSF better off at a large and responsible, albeit resource constrained, organisation such as Oracle, or do you want OmniFaces to take over the spec lead role? If you want, you can cast a vote in the poll below or leave a comment:

Do you want OmniFaces to take over the JSF spec lead role?

Comments

  1. Thomas AndraschkoJune 13, 2017 at 2:37 PM

    Not sure if OmniFaces directly should take over the JSF spec lead BUT the community should do it of course!
    There are many well tested features in many projects which are worth to be included in the specs. The most of them are really small (e.g. a ClientWindowScoped ;))

    ReplyDelete
    Replies
    1. Arjan TijmsJune 13, 2017 at 2:50 PM

      Thanks for your comment Thomas. The number one priority would be that JSF continues and that the burden on Oracle is somewhat lessened, so that the resources that they do have can be applied to some of the other specs.

      If OmniFaces should not necessarily be the spec lead, who would you propose as potential candidate?

      Delete
    2. Thomas AndraschkoJune 14, 2017 at 5:57 AM

      No idea, didn't thought about it - maybe there are other volunteers which would like to do that :) (But not me, i would just like to help in development :D)

      Who is responsible for this decision if the project can be switched over to the community?

      Delete
    3. Arjan TijmsJune 14, 2017 at 6:19 AM

      >No idea, didn't thought about it - maybe there are other volunteers which would like to do that :)

      If there's anyone, please let them come forward ;) We did some brainstorming to think about who else may be qualified, but it's not that easy. It's a very specialised task.

      >Who is responsible for this decision if the project can be switched over to the community?

      Oracle and Ed Burns I guess. It's not at all certain that Oracle even wants to do this though, we're just gauging for interest and offering help, as Oracle themselves have indicated they don't have the resources available to maintain something as big as Java EE.

      So I'd say that first Oracle has to agree with another party leading the spec in the first place, and then the actual spec lead(s) would have to be someone Ed is okay with.

      Delete
  2. UnknownJune 13, 2017 at 9:34 PM

    Yes, absolutely! OmniFaces has all the needed ingredients to lead JSF. For some time now, in a way or another, OmniFaces team is behind JSF development. Is time to make a big step further.

    ReplyDelete
  3. csabeeJune 14, 2017 at 12:32 AM

    I would say, that JSF mostly needs these:
    * better support for responsive pages
    * better page layout support
    * html5 support (I mean real support to create the new html5 tags)
    * a good ui based editor, that would work like a charm (I think most people just hate jsf, because they can't just create a good layout without having to redeploy the application numerous times)
    * maybe webcomponents support


    I personally very much like JSF with butterfaces/bootsfaces, but building a layout is a pain in the ass, no matter what I go with (I can say the same about angular, react, etc.). So I would be very happy to work with it, but nowadays, all those shitty transpiled, packaged, compiled, dependent js frameworks are getting the highlight...

    ReplyDelete
  4. edburnsJune 15, 2017 at 12:12 PM

    I'm glad to hear of your willingness to take it over. Outside of that, I can't comment any further, but I can say that right now Oracle's total focus is completing and delivering Java EE 8 and Java SE 9, and their new capabilities, and we hope to deliver them this summer. I expect we will have more to say about our overall Java strategy and plans at JavaOne following Java EE 8/Java SE 9 delivery.

    ReplyDelete
  5. UnknownJune 15, 2017 at 6:10 PM

    yes we don't want Java to be dependent more upon Oracle but does OmniFaces able to manage every thing and share all things related to JSF with the community ?
    we afraid that we may run away from Oracle and fall into other corporation mercy!
    but in general let's say ok

    ReplyDelete
  6. Dave HamuJune 16, 2017 at 4:43 PM

    When I first worked with JSF in 2004, I thought it was a cute developer toy, but soon discovered that it was far from being a solution for Enterprise scale software development. Nor has it evolved to that sort of solution in the intervening years. I'd be happy if it died on the vine. Today we have Web Components and Angular.js Why should JSF be supported by Oracle or by the Community, and why would OmniFaces want to take the lead in carrying this particular Anchor? I realize that there are those who still love it, but I always wonder "Why?"

    ReplyDelete

Post a Comment

Popular posts from this blog

Jakarta EE Survey 2022

-
At OmniFaces we poll the community from time to time and again about Jakarta EE (previously Java EE) and related technologies. With the transfer of Java EE to Jakarta EE now fully completed and Jakarta EE 10 released , people are now starting to think about Jakarta EE 11 , the second Jakarta EE feature release. As such it's a good time to poll the community again. This year we're doing so in cooperation with OmniFish . In the 2022 edition, there are 4 categories of questions again: Current usage of Jakarta EE Servlet containers APIs related to Jakarta EE The future of Jakarta EE Compared to 2020, we simplified some of the questions once more; again omitting some of the less popular options to make it more manageable. We kept the questions about the future of Jakarta EE and MP together as this issue still isn't resolved. We also ask about the preferred Jakarta EE cadence. As Jakarta EE 10 is the first feature release, we haven't really established a cade
Read more

Implementing container authentication in Java EE with JASPIC

-
This article takes a look at the state of security support in Java EE 6, with a focus on applications that wish to do their own authentication and the usage of the JASPI/JASPIC/JSR 196 API. Update: the further reading section has been moved to my ZEEF page about JASPIC . This contains links to articles, background, questions and answers, and more.   Declarative security is easy In Java EE it has always been relatively straightforward to specify to which resources security constraints should be applied. For web resources (Servlets, JSP pages, etc) there is the <security-constraint> element in web.xml, while for EJB beans there's the @RolesAllowed annotation. Via this so called 'declarative security' the programmer can specify that only a user having the given roles is allowed access to the protected web resource, or may invoke methods on the protected bean. The declarative model has a programmatic counterpart via methods like HttpServletRequest#isUserInR
Read more

Counting the rows returned from a JPA query

-
Despite being almost ten years old, the JPA specification to this day has rather poor support for basic paging/sorting/filtering. Paging/sorting/filtering is used in a lot of (CRUD) applications where the result from a query is shown in a table, and where the user can scroll through the results one page at a time, and where this result can be sorted by clicking on any of the table column headers. In order to support this a number of things are generally needed: The total number of rows (or entities) in the full result must be known There should be support for an offset in the full result and a limit for the amount of rows that will be obtained The column (attribute) on which to sort must be dynamically added to the query Search expressions must be dynamically added to the query As it appears, only offset/limit is directly supported in JPA. A sorting column can only be added dynamically when using the overly verbose and hard to work with Criteria API. Search expressions
Read more