Cay Horstmann, a computer science prof at San Jose State,
Java Champion, and author of some respected books on JSF and Java in the enterprise makes some provocative points in an
interview on java.sun.com, as pointed out by TSS reader John Simpson.
Regarding JSF:
JSC: What are some crucial mistakes that developers make in JavaServer Faces development, often called JSF?
Horstmann: I don't want to blame developers for weaknesses in the framework and deployment platform.
The single biggest issue that hampers productivity is "the stack trace from hell." If you make an innocent typo, your IDE probably won't catch it -- either because the IDEs are not all that savvy about JSF or because JSF was not designed with compile-time checking in mind, for example, with value expressions. Consequently, when you deploy your app, you get a huge stack trace that tells you the life story of the app server. You then must divine which part of the stack trace is relevant and what it tells you about the source of failure. A junior developer can't be expected to do this. All they know is that something failed. So productivity instantly goes down the drain.
Who's to blame? First, the JSF library implementers, for doing a poor job of tracing back the cause of the error to the cause in the programmer's code. Whenever there's a failure, the mantra must be "File name, line number, file name, line number." This is not easy. JSF is built upon JavaServer Pages (JSP) technology. The JSP parser must be rigged to capture the file name and line number of every artifact and to associate it with the data structures that it hands to the JSF implementation.
Second, the app server implementers are to blame for hiding behind the fiction that they produce software for deployment, not development. When something goes wrong, the app server just belches and whines -- it has no pathway to propagate an error with file name and line number to the development environment.
The folks at Netbeans do the best they can, scraping the stack traces for clues. However, they can only report what the app server tells them. The app servers need to have a development mode that tells the IDE the precise file name and line number that caused a failure.
Look at it this way -- suppose the compiler had the same attitude as the app server. If the programmer is slovenly enough to feed it a program with errors, it just returns a stack trace and exits. Nobody could be productive with such a system. Yet this is the fundamental flaw with JSF.
Ouch! There's a lot here - some of which doesn't sound right. (First off, disclosure: I am on the JSF 2.0 EG, mostly with the intent of making sure dumb users like myself don't get ignored in favor of shiny specification bells and whistles.)
For one thing, JSP is
only the default rendering technology for JSF. It's the default because every servlet container is expected to have it, and that lowers the installation burden on the deployer. Blaming JSF because of JSP is a little like saying that leather seats are too hot in the summer in Florida - you don't
have to use it, and if you do, well, you should expect the issues that come along with it. (To wit: in FL, leather seats in the summer are a good way to get burns along your bum and legs, if you're wearing shorts.)
For another, there are a number of IDEs - including Netbeans and Eclipse - that do a very workable job parsing expressions in JSF. There are still some issues with this, in that some JSF tags (like ) can declare a reference to a local variable (and the IDEs tend to resolve managed beans, not local references). Also, the IDEs tend to ignore variables referenced by custom variable resolvers (such as Spring's DelegatingVariableResolver.)
On scripting languages:
JSC: What is your view of the proliferation of scripting languages -- Perl, PHP, Python, Groovy, Ruby -- each ostensibly intended for different domains of application?
Horstmann: You know how to pick my hot-button issues. I think it's great that people come up with new programming languages for research purposes. But these languages ought to die a quick death. What is the point of having Python and Groovy and Ruby and PHP and Perl? I want to learn one scripting language really well rather than dabble in five of them.
From a Java language perspective, Groovy seems the best candidate. Groovy has a Java language-like syntax and a metaobject protocol that makes Grails possible. But it's taken a long time to achieve professional language design, and core parts of the language are still poorly defined and even in flux. For example, I can't really understand the Groovy MOP, except by reading the Grails source code.
I was not happy to see that JavaFX Script is yet another programming language. My graduate student, Sadiya Hameed, is implementing DSLs that have the key operators of JavaFX Script, such as bind and dur, with Scala and Groovy as the host languages. It works just fine. The syntax is a little different but really no better or worse.
Pragmatically, neither language would have worked for Sun at this point in time. I am told that it's important that JavaFX Script can be compiled, so Groovy would not be an optimal host. And graphic designers are probably not ready for Scala. Still, it drives me crazy to see yet another language.
Interesting - and scary. The availability of Python and Ruby on the JVM is a win/win for both the communities of both Java and the other language - Ruby gets an implementation that actually runs quickly, for example. Java wins because it gains access to the various libraries people write in those languages - such as Rails, or the
Universal Feed Parser from Mark Pilgrim. (ROME is great, but ... I'll give the nod to the
bozo bit every time, partly because I'm guilty of producing bozo feeds myself from time to time.)
What do you think of Mr. Horstmann's points?
