The Java Community Process (JCP) has approved a standard for building Web applications at the presentation layer, but the reaction of some programmers so far is that it adds another layer of complexity while delivering nothing they can use.

Java Specification Request (JSR) 127, JavaServer Faces (JSF), was initiated
in May 2001 in order to give developers a standard set of application program
interfaces (API) to build Web applications, as well as a tag
library to interact with JavaServer Pages (JSP) Web pages. API's would be
used for event handling and data validation of servlets ,
delivering graphical user interface (GUI) components back to
the Web page.

In essence, the technology gives Java users a more Microsoft-like programming experiencing, with drag-and-drop buttons, frames, forms and
other visual components normally found in Visual Studio.NET and ASP.NET.
JSF, used with JSP and servlets, is intended to provide a .NET-like
experience for programmers.

JSF separates logic (computations, data) from presentation (Web page) under
the Model View Controller (MVC) architecture, and bears many similarities to
the popular -- and some say complex -- Struts developed by the Apache
Jakarta Project.

Proponents say JSF is a huge leg up with Web application
development, from hard-coding markup-languages like XML and
HTML , and provides more flexibility than Struts, which can only render an element one way.

The specification needs to be incorporated into
integrated development environments (IDE)
tools before Web application
programmers will be able to take advantage of the technology. JSR-127
standardizes the JSP tags and Java classes so that third-party tool
developers have common ground when creating their platform.

With flexibility, it seems, comes complexity. Reactions from programmers at
the developer forum TheServerSide.net, found a lot to be desired in JSF.
Here is a sampling of the comments:

"It's technologies like this that makes you wonder why not everyone
leaves Java for .NET. (think ASP.NET, what JSF should have been like if they
had not insisted on building it on top of JSP)."

" I had a hope that JSF would be a better way than JSP with
TagLibs."

" Lets face it, graphical user interfaces should be designed (and
implemented) using visual tools, not text editors. So, what I hope for in
JSF is not an easier-to-read source file - it is not to have to read the
source file at all."

"After all these years this is what they come up with!? A framework
that makes Struts look like a miracle of simplicity."

No one knows this more than the 32 people on the specification team who
worked on JSF the past couple years. The JSR-127 proposal states that, in addition to a common framework, the creation of "a standard way to define
complex HTML forms and other common GUI elements will enable tools vendors
and third party component vendors to focus their energy on a single
component framework for JSP/servlets."

Jochen Krause is founder and president of Innoopract, a company that
develops a Web application tool called the World Wide
Web Windowing Toolkit (W4T). He said that JSR-127 will take some
getting used to. And although only a fraction of programmers today could use the
specification in programs, he claims it is not too complex.

"If you would have talked 30 years ago to people programming in assembler,
not everyone was happy seeing C come up," he told internetnews.com.
"That's just evolution, putting layers on top of other layers, but it's our
belief that with JSF we get a very powerful layer that makes things easier."

Krause expects JSF critics to quiet down in the next six to 12 months, when
the first JSF-enabled Web applications start hitting the Web portals and
sites. His product, W4T, will include JSF in the coming months, and expects
other tool vendors to follow suit.

Both the JSR-127 committee and Krause believe that with increased use of the
specification, the line between Web applications and desktop applications
will blur, as the API's for GUI components become interchangeable.