Web development in JavaEE7 with JSF, does it still matter?
Development in Java EE 7 with JSF
Does it still matter?
● Java and web development
● Weaknesses (of the past)
● A small story
● Choosing JSF, things to consider during
● Programming in Java since 2000
● In love with back-end code and JavaEE
– JSP(s)... and script-lets (they forced me to ... :P )
– Apache Struts 1.x
– JSF 1.x
– JSF 2.x
Java and Web Development
● Let's face it, the Java ecosystem was struggling
for many years in order to come up with a 'one
to rule them all' web framework.
● From servlets to JSP(s) to action frameworks
(yaay) but always very close 'mentally' to the
● Frameworks getting bigger and bigger, more
complex, steep learning curve.
Java and Web Development...and
● Well, I totally agree, writing web based
applications in the past was not very exciting
● And then JSF came, it broke the existing 'action
● And then....
JSF original Hate
● Complex framework
● Slow, the JSF life cycle is an overkill!
● Non optimal front end support technologies, jsp, facelets
● Steep learning curve
● Far away from the action based frameworks (yaay)
● Poor Ajax support
● Buggy component libraries
● Too many implementations, slow evolving spec
James Gosling..father of Java
'I hate JSF with a passion...'
A small story
● A small team of Java developers (3),different
experience levels, today- 2014!
● Task, re-write a legacy web application (banking, back
● Legacy app... code written in JPS(s), full stop.
● No specifications
● We need it fast, ASAP
● We need something better, dynamic, easy to maintain,
more beautiful, user friendly.
A small story - 2
● So which framework and architecture shall we
● Shall we skip JSF,while embracing all the other
parts of the JavaEE architecture?
● Choose something else?
– GWT? (Vaadin?)
– Pure JS framework?
● Which one?
A small story - 3
● If we choose JSF what are our restrictions?
● Which application server are we going to use?
● What is the existing JSF support on the above app servers?
● What component library shall we use?
● How much time will it take our small team to learn and code
on a different framework / technology?
● What technologies we currently master or we are familiar with
The JSF way – why? - team
● We were a 'pure' Java team, with existing experience on
● We needed something ASAP, so we needed to
leverage our existing skill set.
leverage Ajax and async functionality in our web app.
● I consider JS a maintenance nightmare / a ticking bomb
to many codebases.
– Warning possible flame trigger in the audience – let's start everybody!!!
State of the specification?
● Currently JSF 2.2 – JSR 334 Final
● Part of the Java EE 7 spec
● JSF 2.0, 2.1, 2.2 simplified many ugly things of the past.
● Concrete implementations
– Apache MyFaces
● The spec is evolving, we hope much faster
Application server support?
● This is something you need to watch out!
● All the mainstream app servers come bundled with an concrete
● Oracle Weblogic 12c
– Mojarra (JSF 2.1)
● Oracle GlassFish 4 (R.I.P?)
– Mojarra (JSF 2.2 )
● IBM WebSphere 8.5.5
– Apache MyFaces (JSF 2.1)
● RedHat WildFly (JBoss)
– Mojarra (JSF 2.2)
What we choose?
● We could not change the app server so, the
target application was developed towards
WebSphere 8.5.5 and Apache My Faces 2.1.
● But we could choose the component library,
clear winner, PrimeFaces 4 – amazing features!
● XHTML pages only!
● Standard JavaEE6 multi-module web application
● Maven packaging, no special configuration
● A few entries on the web.xml, initializing the JSF library.
● Package the component library, just primefaces.jar
● Define a template for xhtml pages.
● No initial problems combining standard JSF xthml tags and
specific to the component
● Easy and problem free ..start, a first positive surprise!
Learn as you code
● Different levels of JSF coding experience.
● 3 man days of reading through JSF 2.1 specifics.
● Lot's of free resources and available books
– JSF the complete reference, Ed.Burns
● God bless to JSF heroes and dev community
– BalusC (http://balusc.blogspot.com/)
– StackOverflow, JSF section
Some basic guidelines
● Keep the code simple
● Make sure everyone understands the basic
scopes of Managed Beans
● Avoid Session Scoped Beans.
● Code using lean and clean entities (dto's)
● Code all the 'table' section of pages with lazy
Some basic guidelines - 2
● Identify 4-5 core use cases and apply the same
● Try to leverage the rich UI built in support of the
components rather than doing it your self. No extra
JS plz..no extra JS plz..no extra JS plz.
● Make use of Client Side Validation (Primefaces)
along with server side validation (JSF).
● Localization comes cheap :)
● We managed to resolve corner cases as we developed
concrete examples, fast enough.
● We were amazed that most of UI requirements were
already covered and implemented by the component
– Lazy data models
– Async form posts
– Ajax support
– Partial form submits
– Another positive surprise!!!
● JSF code integrated naturally with any pre-
existing code we had already developed e.g
JPA2 beans, and EJB(s).
● A simple and clear separation of layers that is
easy to be taught and followed, by junior
● JSF built in error management and handling,
helps you identify easily bugs and resolve
● We used CDI, but we felt that there is still room for
improvement when you mix different annotations together.
● We would be happier if our app server was more flexible
on allowing us to experiment with another JSF
engine.Some app servers are more flexible.
in a jsf component)
● Our app can easily migrate from Websphere to another
Why you should consider JSF
● If you are already a team with core Java skill
set and you want to use this skillset asap
● JSF 2.x is and it's concrete implementations
are far easier to use and grasp comparing to
● Lot's of documentation and support.
● All major app servers support it and come pre-
bundled with an existing implementation.
Why you should consider JSF
● IMHO it is easier in the future to maintain an aging Java code
base rather than a JScript one.
● Freedom of choice, you can de-couple the choice of which
JSF implementation to use and what component library.
● Many component libraries offer amazing out of the box
functionality for free! No need to re-invent the wheel.
– Many libraries offer out of the box rendering to mobile clients with no
Why you should consider JSF
● JSF 2.2 introduces HTML 5 support (html 5 friendly mark up)
● Extended support for complex implementation cases e.g Faces
● Added more Explicit CSRF support
● Do not forger that from JSF 2 and onwards 'partial state saving'
when submitting forms and stateless mode are supported.
– Meaning, yes you can scale to thousands of users,and your session
does not have to be hundreds of MB(s)
Is it late?
● JSF is around more than 10 years
● Some people argue that it's maturity came very
● I believe that as long as web development in
the form we currently know it (for the browser)
is relevant, JSF will be a valid choice especially
for teams with Java Developers.