Thank you for taking my question! This is a huge one to us. I imagine that the answer may be different, depending on the person that is answering the question. What are YOUR personal thoughts? We are still on RichFaces 3.3.1. As you may know, Richfaces reached end of life officially (last year). At some point we will be upgrading to an EE 7 Application Server (mostly likely JBoss EAP 7). Please place yourself in our shoes, would you PERSONALLY stick with RichFaces 3.3.1 (forever? if possible), possibly (painfully) upgrade to RichFaces 4.5 (forever?), or (even more painfully) move to something else entirely (like a PrimeFaces for instance) to avoid any future end-of-life vendor abandonment issues? If you choose to accept it, this is your challenge, please give a detailed thoughtful explanation so that I can further "sell" it to management and the rest of the team. (By the way, Primefaces+possibly OmniFaces is where my head is currently.... "No pressure")
This is a hard question to answer, because I of course don't know anything about your web application(s), how large and complicated they are and how much time and money it would cost to (partly) rewrite them using a new version of RichFaces or a different component library or even a completely different web application framework. Also, I'm not very familiar with RichFaces so I don't know if upgrading from RichFaces 3.3.1 to 4.5 is a lot of work or not.
It's often hard to make a good business case for these kinds of projects - the management of your company might not see the need to upgrade software, since the current version works and any changes will cost time and money and add the risk that bugs and other problems are introduced. But the risk on the other side is that if you wait too long you'll end up with software that becomes hard to maintain, and the longer you wait with upgrading it, the more time and money it's going to cost to maintain and upgrade it in the future, up to the point where the whole application needs to be rewritten from the ground up.
So, it's hard for me to say what would be a good idea for your specific web application(s), but if you want to convince your management, think hard about what the advantages, disadvantages and risks business wise would be for them for the different options, and show them that doing nothing and leaving the software on the old version means that it's going to be more expensive to maintain and upgrade in the long run.
Of course, if it's too much trouble, Red Hat will do the conversion for you. For a fee.
The primary source of agony moving between the two versions has to do with AJAX support.
In RichFaces 3, AJAX support was provided by extended tags. In RichFaces 4, you have to re-design your controls to use the JSF2 standard ajax tag. The signature of the AJAX callback method is different as well, so both View and Model have to be changed. Because they didn't provide an interim mechanism, every page in the app has to be migrated at the same time.
Aside from that, there are a few annoyances like changing how things are capitalized and various odds and ends listed on the RichFaces site.
When I found out that converting from RichFaces 3 to RichFaces 4 was an all-or-nothing affair, I was livid. I've seriously considered switching to some other extension tag library because of that. The biggest app I've got is still trying to migrate from pre-JSF code in many places, much less RichFaces, and since the owner owes on past work, I'm certainly not going to do a total overhaul.
Tim Holloway wrote:... but Java is supposed to strive for backwards compatibility and soft migration paths
This is ofcourse true for the Java programming language itself and the standard Java API and also everything in Java EE, but not necessarily for third-party libraries such as RichFaces - they're not always as cautious as Sun was / Oracle is to maintain backward compatibility.
It's much the same as the Unix-Linux "Do one thing, do it Well" philosophy which was violated when systemd was put into place. Many people were enraged and continue to be enraged.
We expect better things. And while I've always ragged on people that software isn't "Write Once/Run Always" and should be maintained, that doesn't mean that I approve of forcing people to do all the maintenance at once.
...but not necessarily for third-party libraries such as RichFaces ... Many people were enraged and continue to be enraged...
We're on the bandwagon. That's one of the reasons we didn't upgrade to the JBOSS EAP 6 application server. Without our firm commitment by us to upgrade our RichFaces, for RichFaces(3.3.1)-based apps specifically, does it even make sense to upgrade from JBOSS EAP 5 (Java EE 5 Application Server) to a Java EE 7 Application Server (likely JBOSS EAP 7)? At the same time, obviously, there is the concern that Jasper spoke of.
Regarding "all-or-nothing", and we have not begun to explore this so I apologize up front if this question is nonsensical (but we do currently maintain various JBOSS EAP servers currently), is it possible to just develop new features only for RichFaces 4(.5) for EE 7, while "simply?" maintaining our EE 5 server with RichFaces 3(.3.1) with our existing features. (All of the old features would be on the old server, while all of the new features would be on the new server.)
If you have any informative "goto" reference links lying around close at hand, please advise.
...- they're not always as cautious as Sun was / Oracle is to maintain backward compatibility.
Jasper, Tim, and/or anyone else please: Not necessarily for upgrading/migrating purposes, but perhaps when starting from scratch and future-proofing (assuming there is such a thing), is there now or will there be in a future version(s), a (JSF-based [RichFaces-like]) third-party library that "excels" , touts, and/or is better at backwards compatibility? (Does this simply come with the territory of being clearly outside the (Jasper:)"the Java programming language itself and the standard Java API"? This of course means that perhaps MVC 1.0 may prove to be invaluable?)
Have a look at the video presentation in this post from Oracle: Java EE 8 Overview
Especially the part that starts around 21:00 minutes into the video, where Linda DeMichiel explains there's a shift in focus; a few minutes later there's a slide with JSRs that are proposed to be dropped from Java EE 8, which includes JSR 371 - MVC 1.0.
So it could be a while before this MVC frameworks gets into Java EE; it probably won't be included in Java EE 8.
Also, the MVC framework works in a completely different way than JSF. It's an action-based framework instead of a component-based framework. If I'd want to go for an MVC-based framework today, I'd choose Spring Web MVC, which is mature and stable. The maintainers behind the Spring Framework do care about backward compatibility.
I don't think RichFaces is baked into any webapp servers the way that the core JSF is. So any individual webapp can be running either pure RichFaces 3 or pure RichFaces 4. You just cannot mix the 2 in a single webapp - no partial or at-your-convenience migration.
Technically, I don't think that RichFaces 3 is supposed to be used under JSF version 2 at all, but in actual practice, I've been doing so in production for years now. You don't get 100% functionality - I think that the JSF2 jax tags get dinged, for example, but the majority of the functions work.
I'm not spending much time in that zone at the moment, I'm running JSF2 on cloud servers. At worst, it might be dropped from the standard and have to live on its own. But that never hurt Struts, Wicket or Spring Web. The core JSF implementation was always multi-sourced anyway. I started using Apache's MyFaces before moving to Mojarra. Oracle's long-term stated goal has been to fracture the Java platform into a la carte subsysems anyway, so JSF might simply become one of the add-ons.
Also, the furor isn't about instability in JSF itself - that doesn't seem to have backwards-compatibility issues unless you invested heavily into writing binary tags or haven't yet moved on from JSF 1.0 raw JSPs (and Facelets was brought in while JSF1 was still the standard, so I for one had already migrated before it became an issue). The problem here is with a specific vendor's extensions to JSF. Other vendors may be offending as well, but I haven't had to suffer with them.
As I said, there are other implementations of the standard spec such as MyFaces and they have their own maintainers, but the reference implementation is Oracle's.