All 3 entries tagged Java
July 21, 2005
There's been a "what advantages does JSF have over Struts" thread on the MyFaces list in the last couple of days so I thought I'd put together a summary.
- Fewer and less verbose config files
- Automatic type conversion of bean elements (not forced to use String)
- Bi-directional conversion between browser info and bean info, not just decoding
- Validation and conversion are more robust, re-usable and extensible
- Large and rapidly growing set of UI components – richer and more reliable UI
- UI components are more reusable
- Using standard (JEE) components maximises ability to hire developers who will understand them and is thus a safer choice (in the long run, presumably)
- Better tools are available
- Allows RAD (by building view first)
- Lifecycle events are standardised and extensible
- Eliminates all logic in JSPs
- Dependency injection is considered best practice these days
- JSF's bean injection virtually eliminates the need to directly access the Session and Request objects, reducing coupling and increasing reliability
- Rendering is decoupled from the view, so can use JSF for rendering to mobile devices
- Cleaner MVC model – is an ActionForm part of the controller (action) or view (form)?
- More flexible navigation because navigation rules are decoupled from actions
- Less coupling to the framework in general
The last point was only touched on briefly somewhere, but for me it's one of the key points. My view (since JSF 1.0 came out) is that the JSF framework is cleaner and does more of the dirty work for you, but the lack of coupling means more of your application to be written as POJOs – the same advantage as technologies like JDO and Spring.
June 27, 2005
Some good new stuff coming in Netbeans, much of it focussed around existing strengths such as GUI design (the new GUI building engine looks excellent), cross-device development (setting breakpoints in a mobile phone is cool) and out-of-the-box usability. Netbeans does seem to be kind of the most agile IDE; they're already talking about integration with Looking Glass, the 3D desktop.
In general, the priorities with Netbeans coincide with those for Java generally, around ease of use (supporting higher level constructs and working with a variety of platforms) and dynamic languages. Early leak: the Dolphin release of the JVM (2008) may include byte code to support dynamic languages, which will be the first byte code in there that isn't used by Java itself.
The fireside chat featured a real fireplace, though it wasn't lit (no surprise, since it was on stage in one of the conference halls and the flue only went up to the top of the stage set). It's purely an audience Q&A session with the top people who shape the JVM, platforms and APIs. No overall theme, therefore, but interesting to hear the kinds of questions asked. Much interest in support for phone/PDA devices. Worst regret in 10 years of development of Java: AWT. Deprecated APIs will never be removed from the platform. JDO will not be deprecated (though since all the big JDO vendors are involved in EJB3, it may not develop much further after the EJB3 compatibility revision). Annotations will be developed further, but otherwise no major new language features planned for the next two releases – witness how long it took to standardise generics (over 5 years). Mantra of Sun Java developers is like the Hippocratic Oath: "do no harm".
June 03, 2004
Chris May wrote, in a comment to one of my earlier entries:
Scriptlets are morally wrong (and may make you go blind) anyway
I don't think scriptlets are that bad. I don't think they break the Model-View-Controller pattern (not that I'd care much if they did) – if you need logic to traverse a data structure in order to emit table rows, or to make a button look different according to some attributes of the user viewing it, that is surely view logic anyway. And they have the advantage that, in my experience, they are the quickest way to build web pages. Sure, in an ideal world all code would be in nice neat classes, but in a world with ambitious and immovable deadlines and barely enough developer time to meet them, they're a good way to get going quickly. I think the worst you can say about them is that because they're less structured than classes, they're harder to maintain. But sometimes you need to sacrifice maintenance to meet delivery deadlines.
I was never sure how I felt about JSTL as a technology and by now I'm firmly against it. Putting logic inside custom tags on a web page has all the maintenance difficulty of scriptlets, with some added because of the lack of transparency. Custom tags are a bit like operator overloading in C++ – a double-edged sword, concise but capable of hiding important goings-on. In addition, because they're interpreted rather than compiled they're slower, and they require the developers and maintainers to learn a whole new dialect. And because of the logic is expressed in a different dialect, you can't do what you can do with scriptlets, which is when you realise you want to re-use code (or just improve its organisation for ease of maintenance), you can refactor it straight out of the JSP and into classes. JSTL just has to be copy-and-pasted to be re-used. Now enough of that will make you go blind.