Until JSF 2.3 the mojarra (reference implementation) and myfaces were based on JSR specification document.
With a move to the EE4J:
Would there be any equivalent of specification document?
how does it impact the future of other implementation (myfaces for jsf)?
Will the future mojarra and myfaces still be compatible so that we can run an application on either of them ? (implementation provided by the Application server - WAS = myfaces & glassfish = mojarra)
What impact could it have on component framework like Primefaces ,Bootsfaces etc which depend on a underlying implementation?
Update August 19, 2018: Guillermo González de Agüero recently gave an interview at Jaxenter.com addressing some of your questions. In particular, he's a bit worried that Oracle won't open-source the specification documents. That'd prevent simply taking these documents as a basis for new specification documents.
Update August 17, 2018: After writing my initial answer, I reached out to some of the leading JSF developers (see this discussion on Twitter). There are plans to purge outdated APIs, such as removing the old JSF ManagedBeans in favor of CDI. So there will be API changes, but I don't thinks that's something to worry about. I'm sure there will be a smooth upgrade path.
It's always difficult to make a prediction concerning the future. However, I'm a bit closer to the people in the spec teams than most, so I can make some educated guesses.
EE4J is part of the Eclipse foundation ecosystem, so I'm sure there will be a well-defined specification process and a lot of documentation. I'm almost sure there will be a detailed specification document, but take it with a grain of salt - I'm not an insider. (Also see update above - currently, the specification documents of JavaEE are under copyright protection, and it seems unlikely they're going to be donated to the Eclipse foundation).
As far as I can see, there's not much impact on MyFaces. They just have to follow a different specification document.
Definitely yes. MyFaces is an actively developed project meant to be a plugin replacement of Mojarra. That won't change just because the reference implementation went from a big company to the Eclipse foundation.
There won't be much of an impact to PrimeFaces and BootsFaces. Both projects will remain compatible to both Mojarra and MyFaces, and to every current version of JSF. There are other JSF libraries such as HighFaces which rely on internal API of Mojarra. But even in this case, there won't be much of a change.
In any case, I don't expect major breaking changes of the JSF API in the near future (apart from purging outdated APIs, such as dropping support of ´ManagedBean`). The strength of the Java world has always been backward compatibility. But again, that's just an educated guess, so take it with a grain of salt.
Related
I am on the hunt for a extra component library to the core JSF 2.0 library. I need calender-pick, tabbed pane, tree view and other nice components to complete my Java EE 6 - Glassfish 3 project.
But I don't know which additional library to choose; MyFaces, OpenFaces, PrimeFaces, etc. I never tried any of them.
My most important requirement for the additional library I choose, is the footprint in bandwidth and memory it will make. It has the be a lightweight library, because the web-system is used by many users in the developing countries, where bandwidth is far from what we have in US/Europe. Plus it would be nice if there is some RAID editor tool for the web-designers people to use when designing the View/GUI part. Thought of Dreamweaver, but I don't know if it can render the components (JSF core and Faces libs)?
What additional Faces library do recommend me to choose?
RichFaces seems suitable option. You can use JBoss Tools (Free) as WYSIWYG IDE. It is being actively developed and maintained. The new version 4, will work even better with JSF2.
To conserve bandwidth you may need to look at compression techniques on static resources.
I am currently developing an internal application for our company with the following requirements.
Rich GUI but only basic HTML like components will be used. So component list is not a deciding factor.
Fuzzy requirements which might change frequently during the implementation stage, and tight turn around times are the norm. Thus am looking for a Drag-&-Drop design
The application will rarely be used (max once in a month) and the user base will not exceed 20.
Time is a critical factor and thus I do not want to spend time on configuring and troubleshooting the framework. I will go for a easy to integrate solution.
I did a brief research and decided on JSF with IceFaces. But am now confused about the version. If I go with 1.8, I get Drag-&-Drop designing (Netbeans 6.5) but I will be stuck with JSF 1.2
If I choose ICEFaces 2.0 I will have to manually design the UI which might take more time.
Any suggestions on which version to choose?
If you can, go with the newest stable version. There are a lot of reason to use JSF2.
You can have drag&drop with ICEfaces2 too, at least in Eclipse (see the wiki). IDE integration is available for NetBeans, the release note mentions a palette (I'm not familiar with NetBeans, but it may be what you're looking for).
Currently, my web-application is based on the following libraries / frameworks / tools:
Java 1.6
JSF 1.2_07-b03-FCS
Facelets 1.1.14
Richfaces 3.3.2.GA
EL-Functors 1.0.2
Spring 2.5.2
Tomcat server v5.5
Some additional information:
Spring is in charge of managing all the beans used by JSF (org.springframework.web.jsf.DelegatingVariableResolver is defined as the variable-resolver in my faces-config.xml file).
EL-Functors is used as my el-resolver in order to extend the Expression Language.
I've created many custom components, some of them are just Facelets compositions, others are Java-based components (some of them are extending Richfaces components).
I want to try (essentially for curiosity, but if this works well, why not for real?) to migrate my application to JSF 2.0.
Question #1: what are the critical points that I must consider in order to make my application working correctly?
I am talking here about just having a working application, nothing less, nothing more.
I alread know that I will have to review all my custom components, because I will use the new version of Richfaces (4.0), and also see if they work correctly.
Question #2: what will be the first steps to achieve to take advantages of JSF 2.0?
Some ideas I already have are:
Remove EL-Functors and use the Expression Language 2.2;
Let JSF manage the beans, and use the #ManagedBean. Or maybe switch to a CDI library, such as Weld?
Use <f:ajax> instead of <a4j:support>?
Regarding JavaEE6
I know, a good idea would be to completely move to JavaEE6. I'd liked to do so, but for some reasons I just can't do that way. One (bad) reason is that I must stay on Tomcat servers.
However, I can add new third-party libraries in order to have some JavaEE6 features, such as EL 2.2...
So please consider this aspect in your answers.
Regards.
Since Richfaces 4 is still under development you may want to use Richfaces 3.3.3 with JSF 2.0.
Thus you have to use Facelets 1.1.15 as described here http://community.jboss.org/wiki/RichFaces333andJSF20
This implies that switching from a4j:support to f:ajax won't work with your Richfaces based components so I suggest to stick to a a4j:support. This will also keep the migration effort low if you decide to switch to Richfaces 4 as soon as it is available.
Since you already use Spring to manage your JSF-Beans there should be no need to use the DI-Features of JSF2. I'd stick to Spring but consider an update to Spring 3.
Besides this, Weld is definitley worth to take a look at.
HTH
If you plan to stay with Tomcat, then moving to Java EE 6 means you're going to be looking at Tomcat version 7.
But if you want a full-fledged Java EE 6 server then GlassFish 3 or JBoss 6 is a better alternative. Tomcat can be iffy when you try to do certain thing like CDI (Weld) or EJB 3.
Just my two cents worth. Hope it helps...
Just a general question, open for discussion...
I'm very much liking JSF so far, I'm new to it, but I prefer it to Struts. From a professionals standpoint, do you see a strong future for JSF ? Is it worth an investment as a young programmer to learn JSF 2.0 over Struts or another similar framework ? Should I stick to regular JSP ? Is Ajax really simpler through JQuery than JSF ?
I like new technologies and I like what I see so far from JSF but I want to be practical as well, and a lot Google searches turn up some bluntly critical comments about JSF 2.0.
Thoughts ?
Comparing JSF with Struts is like comparing apples with oranges. Struts is a request/action based MVC framework while JSF is a component based MVC framework. Struts is also aged. In the IT you're supposed to keep moving. Generally, a component based MVC framework is seen as a further evolution of a request/action based MVC framework.
JSF is currently already used very widely. It has indeed received a lot of critism before. You can read about most of them in the question What are the main disadvantages of JSF 2.0? The strength of JSF is mainly being a Java EE maintained standard and the availability of relatively a lot of 3rd party component libraries (PrimeFaces, RichFaces, IceFaces, OpenFaces, Tomahawk, etc). With JSF, it's very easy to develop CRUD applications and web forms with nice look'n'feel quickly.
However when it goes into the complex, JSF may cause some unforeseen surprises. Although the JSF specification and reference implementation (Mojarra) is pretty mature since the latest 1.2 builds, you may encounter some very specific behavioral problems which goes against your intuition. Some are just "by design" and can only be understood when you understand in detail how JSF works under the covers which in turn often boils down to the stateless nature of the HTTP protocol. JSF abstracts it in essence "too much" away that you don't see it anymore. Some are just bugs in the 3rd party component libraries used, but that's thus not strictly JSF-implementation-specific. Bug/issue handling is however pretty good in most of the major component libraries -if you report the bugs timely.
As to ajaxical stuff, JSF 2.0 indeed provides very little manual control over manually firing ajaxical requests and controlling the view tree in both server and client side. Simply because it's a component based MVC framework which keeps the tree state at the both sides. You've got to take the both sides into account when taking the ajaxical works in your own hands. If you really need more freedom in ajax/request based actions, then a component based MVC framework is simply the wrong choice. You should pick a request/action based MVC framework instead like Spring MVC, Struts or Stripes, along with a JS library like jQuery. You however have to write lot of HTML/CSS/JS boilerplate yourself instead.
I am begining a web system and can't decide what technology use! Struts2 and JSF (with jboss seam) are a nice choices, but I can't decide which's better. In JSF have some that I don't like, maybe its "paradigm" no action like. And Struts2, the peoples here don't use more.
The system is a map collaborative web site.
I have used both Struts2 and JSF extensively, both are good but I would still recommend JSF. Here is why.
More users. Yes this counts; more people means its easier to get hands on new programmers.
Better tool support. IDEs like IntelliJ have very good JSF support.
Facelets. Lets face it, JSP sucks. You simply should not be allowed to write business logic inside your view code. Keeping your views in XHTML ensures that they are clean and tidy.
Documentation/Books. This might have changed, but when I was in the struts2 camp (2007/2008) the books available was few and of very poor quality. There is a good choice of JSF/Seam books.
JSF2/Seam. JSF2 is very nice (and IntelliJ 9 supports it). New scopes, such as the view scope, are really helpful (fx. if you are having a long running conversation in a flow).
If you are interested in some of the newer features in JSF2 then checkout this blog post. Also you might want to check out Stripes, it is also a very nice server side web framework and finally here is a very thorough (and a little old) comparison of most Java web frameworks.
This a very debatable topic. I think the main advantage of Struts2, compared to JSF, is its simplicity, it is much easier to grasp. Specially for beginners in web programming, or those familiar with "action based" web frameworks (Struts 1, Webworks, Spring MVC, Stripes).
But Lars Tackmann's points are valid (though Struts2 does not force you to use JSP; and indeed it uses FreeMarker internally). It's true that Struts2 has not attained a big user base, the community (both users and developers) does not seem to be very active, and that is a big minus. JSF also has its shortcomings, I've heard (I've not used it)... as every Java web framework, it seems.