October 2006 Archives
At JavaOne 2005, several of the Struts developers (Martin Cooper, Don Brown) sat down with Rich Feit (Apache Beehive) and a few Struts users to discuss the future of Struts. We came up with the Struts Ti proposal, which described a framework that brought together a lot of good things that were developing in the web framework community. The problem is that the Struts 1 code base didn’t lend itself to drastic improvements, and its feature set was rather limited, particularly lacking in features such as Ajax, rapid development, and extensibility.
At the same JavaOne, I sat down with Jason Carreira of the OpenSymphony WebWork 2 project to discuss how we could better work together. I was interested in building on XWork, the core of their command pattern implementation, but he suggested building on WebWork 2 directly. As Rich and I worked on the first few versions of Struts Ti, we decided to take Jason’s advice. We thought it was time for a framework to address higher level application needs, and by building on the proven WebWork 2 framework, we could spend our precious spare time where we felt it would make a difference. From then on, Rich and I worked mostly with Patrick Lightbody, also a core WebWork 2 developer, and found ourselves constantly “stealing” each others ideas for our respective code bases.
Around this time, Patrick and Keith Donald of the Spring WebFlow project were kicking around an idea of a web framework to bind them all, Clarity. Clarity brought together Spring WebFlow (Keith), Struts (Ted Husted and myself), WebWork (Patrick and Jason), and Beehive (Rich) to talk about the possibility of combining efforts into one framework. Unfortunately, the devil is in the details as soon as Beehive and WebFlow were unable to make progress on merging their wizard/conversion scope features, and questions about project ownership, brand, and identity soon broke up the party.
Wouldn’t it be cool to take java’s slogan “write once, run everywhere” and implement it on other things? For example, we can create an Ajax API that decouples the server functionality from its implementation. One would be able to replace the server implementation (lets say from PHP to JAVA) and evaluate performance, stability and scalability variations without changing the web application front-end code itself. Creating such standard API will result in several server-side implementations (hopefully, some of them open source) competing over the web developer community, this competition will mean better products.
AJAXDO is an example of front-end and server-side decoupling. A full blown standard should include, among other things: security, object passing/storing, some sort of server-side business logic invocation, and even transactions. Now with rise of activity around web 2.0 applications and software-as-a-service concepts it might be a good time to start working on such standards.
What should this front-end and server-side decoupling standard contain?
On a recent client project, we ended writing more than 300 business rules to reflect some of the financial decision making that they applied to an application (excuse me if I’m being suitably vauge with this). Many of these rules would be shared across applications. The rules engine used was the Java based JBoss rules engine (formerly known as Drools).
Obviously , these rules need to be stored somewhere. Most large organisations are comfortable with the idea of using a Database such as Oracle or Sql-Server to carry out this task. This article , for version 2 of Drools but also applicable to the latest release, shows you how to use a database to store your business rules.
The next Groovy and Grails User Group meeting will be Thursday, October 26th, 2006.
I’m using Oracle Sql Developer (formerly Raptor). It’s a nice little tool to view information on an Oracle Database (and much better than Sql Plus, which was a throwback to the 1970’s). Maybe it doesn’t have all the power of Toad or Sql Navigator, but that doesn’t matter , it’s free , can run anywhere (it’s Java based) and does most of what you need.
The reason for the post? Opened it up today, and found that it has an auto-update feature (a la Eclipse). It now has support for Oracle Reports , Oracle Data mining as well as a nifty Sql formatter. It will be interesting how the commercial tool providers (like Quest) respond to this!
The main reason for using Sql Developer as a Java person is that allows you to test your connections; simple copy and paste your JDBC Url from your Java application, and hit the ‘test’ button. No longer do you have to pull your hair out as to why your lovely ajax web application no longer works , only to find somebody has changed the DB username and password!
It was just pointed out to me that MathEclipse is now using a GWT front end that is pretty cool.
MathEclipse is really cool, and I must say, a tribute to the quality of math and science APIs available for Java. Built with JScience, Jakarta Commons-Math, JavaView and Javolution on the server, and now with a swanky GWT front end, it really is a very useful site. It makes me think of the Webbish Mathmatica to go along with everyones Webbish Word Processing and Spreadsheets and IM clients we are all starting to adopt.
There was recently an article that Steve Anglin linked to touting Java’s performance on Windows Vista. Toward the end of the article, the author mentioned that the platform of choice for Vista is going to be the soon to be released Java 1.6. 1.5 will also be supported on Vista (it will work), and the article said the 1.4 will work, but it’s not a big priority. On Macs, there’s a whole different calculus of which version of Java to use because anything lower than 10.4 will not support 1.5. Without getting into the details about the installed user base, and the economics of the particular business application I’m building i tell you the decision tree I went through to chose the base level VM version for a client application that needs to be released in the middle of ‘07:
* 1.6 was ruled out, it’s too risky. I mean that’s not to say that it isn’t something that will work out of the gates, but I tend to give Sun a few months to work out the kinks in any new VM release. Plus, I can’t expect to dictate that people upgrade to 1.6 when I’m not sure what sort of support 1.6 will have on existing platforms. Again, this isn’t FUD (you Sun employees don’t need to start a flamewar). But, 1.6 is not the right choice for a widely distributed retail client application yet.
* 1.4 was ruled out, it’s likely to see support end in the next two years (my assumption). Plus, it’s going to work on Windows Vista, but I’m going to have to expect that the support of 1.4 is going to stop sooner rather than later. Plus, how old is 1.4 now? Many years. From a business perspective, building on 1.4 is somewhat risky because of what I read on that Vista blog entry - people at Sun are not focused on getting 1.4 to work on Vista, if it isn’t getting the same level of attention, it’s more likely to be something that will remain unpatched when 1.6 and 1.5 are the priorities.
* 1.5 was selected. It is going to work on everything OSX 10.4 and up, it’s going to work on (at least) Windows XP and up. It is sufficiently mature and stable. and, the real reason…. I can’t program without both annotations and generics. Plus, all the fancy stuff I want to write about uses 1.5 anyway.
The only place I could see myself using 1.6 is in a server-side application that needed the new support for dynamic languages. In that case, I’m not sending bytecode out into the wild, and I have full control over the operating environment.
Share your own thoughts and experiences?
Please post a comment if you have your own thoughts on this. Especially if you have any “inside” knowledge of support plans. :-) It would be interesting for everybody to see what the current thinking is on which version people are building applications for? I’ve assumed 1.4 and up, but I’m sure there are still people doing battle with 1.2, out there.
On InfoQ.com, an opinion piece has just posted: Use an Eclipse-style governance model for open source Java?
Today, Chris brings up Runescape as an example of a Java app people actually use. I have to say, RS is pretty cool, and I do know some people that play it fairly regularly — it is great for the non-hardcore-EQ-geek crowd to get their MUD on.
Another one I would like to point out, though is Puzzle Pirates. It is the MMO expression of the casual games phenomena and really quite clever. Not only is is written in Java, but Three Rings has open-sourced their game framework code and even have a pretty clever offering called Game Gardens which is rather like the Second Life of casual games — create your networkable puzzle/board game and they will host it on their servers.
As you probably know, Jetty is a web server (and servlet container) written purely in Java. Because it is small, fast and has a well designed configuration API it is often used as a embedded server in various Java applications (Continuum, FishEye, …).
Of course, when you use Jetty in a Spring-based application, you will want to configure it as you configure the rest of your application (as a Spring bean). Since it has a well defined configuration API, this is not a problem to achieve.
TheServerSide.com is reporting news that the Spring Framework 2.0 is now final.
After introduction of Test Driven Development (TDD) there was only one “testing related mantra” for developers:
write test, write code, refactor
and that was the point were all further discussion stopped. Of course, this is only the introduction to this topic as there are many other factors that should be considered in order to deliver quality software to your customers.
Finally, in past few months I ran across few articles (and blog entries) that broadens discussion on this very important topic. In this post I’ll collect them in one place and summarize their content hoping that they will be a valuable read to you (as they were to me).
Steve Yegge has a provocative blog about Agile methodologies. It’s vintage Steve: fun to read, cutting, opinionated; and, in many ways, largely right, I think. A couple of quick reactions:
The one component of “agile programming” that’s very much part of Google’s culture is unit testing, and that’s always seemed to me to be the most valuable part of agile/XP. When I was at the Googleplex in August, they even had exhortations about unit testing posted in the mens’ rooms. That’s certainly a deep part of the Google culture.
One of the follow-ups pointed out that the nature of Google’s business means that there isn’t the sort of time pressure you have when a customer is screaming for a new feature that he wants last month. That’s certainly true, BUT: At the same time, I’m seeing more and more companies have businesses that are built along Google’s model. Certainly every interesting start-up that I know of. (That begs the question of the uninteresting start-ups.) The perpetual beta does as much to eliminate the pressure for “FCS” as it does to encourage creativity. The perpetual beta, first formulated as “release early, release often,” is one reason behind the success of many open source projects over the years.
In defense of Agile methods, Google’s development methodology works largely because Google only hires very smart people. Don’t ask me how they found that many smart people, even in Silicon Valley. I’ve lived there, and I know that the density of smart people isn’t that much greater than it is anywhere else in the world. Anyway, one of my observations about business in the non-Google world is that a huge amount of it is getting people who really aren’t very bright surrounded by a process that somehow enables these people to turn the cranks and come out with something good at the other end. (I say that with all due respect to my readers, who I assume are the “bright” people at the top of this food chain.) Security audits, code reviews, waterfall, and even Agile: it’s really all the same game. And the “good” that you get from the end of the process is for a fairly tolerant value of “good”. More like “it doesn’t suck too bad”. But that’s the way most companies work. It’s a fair question: how broadly applicable is a methodology that assumes that you can hire people as smart as Google’s staff? Most companies can’t.
Yes, I know that Google engineers don’t walk on water. The deeper question is: with the sort of incentives that Steve describes at Google, could the average performer be motivated to do good work without the process? Or is the existence of the process itself important?