Comments on: Very strong performance JHeadstart in virtual RAD race – Personal Best set at 34'52" Friends of Oracle and Java Thu, 30 Oct 2014 05:50:12 +0000 hourly 1 By: Steven Davelaar Wed, 07 Dec 2005 08:33:50 +0000 It is certainly true that the primary target of JHeadstart is transactional data-oriented web applications. And yes, in any project of reasonable complexity, you will need postgeneration modifications / extensions to the generated screens. 100% generation is certainly not a goal in itself , although some people like Lucas (and myself) like to stretch the capabilities of the JHeadstart Application Generator as far as possible. Take a look at the jheadstart web log ( for other advanced examples like generating wizard-style screens.

With Oracle Consulting, we use JHeadstart through the entire lifecycle of the project. Apart from Design and Build, JHeadstart is a great help during Analysis when you want to apply an iterative/agile approach. Nothing better then showing some working screens a few days after a requirements workshop to validate user requirements!
Using ADF with JHeadstart, Oracle Consulting is able to offer J2E E projects using the same productivity figures as we do for Designer/Forms projects. That would not be feasible if JHeadstart would only help during the first days (or even minutes :-) of the project.

Many people associate application generation with increased productivity and decreased flexibility. We believe that one of the strongest benefits of Jheadstart is that is does NOT limit your flexibility. We do not generate any java code that is hard to maintain, just UIX/JSP pages, and a struts-config that is build on a generic, very extendable Struts action class.
The runtime architecture you get is the same, whether you use JHeadstart to generate, or you start with drag and drop from the beginning. Only if you force yourself to stick to 100% generation, you are limiting yourself to what JHeadstart can generate for you.

By: site admin Tue, 06 Dec 2005 05:38:27 +0000 Jan, you should then use it like this: “JHeadstart speeds up what are the first 35 minutes when using JHeadstart or the first three weeks when not.”

And of course JHeadstart is a productivity booster – surely you gathered that much? And at the same time, the exact benefits depend on the project involved. If you do not build against a database, there are virtually no benefits. If you build a WebService frontend – again no substantial benefits. Data-oriented OLTP style Java/J2EE Web Application: yes, that’s the one. And I know we both have been building quite a few of those.

By: Jan Mon, 05 Dec 2005 20:54:33 +0000 Well okay then, what are you guys saying? Is ADF/JHeadstart a productivity booster or not, or does it depend on the project involved? @Rob; I really liked your slogan – I’m definitely going to use this one myself if you don’t mind ;-)

By: Rob van Maris Mon, 05 Dec 2005 17:15:55 +0000 Nice slogan: “JHeadstart considerably speeds up the first 35 minutes of development!” ;-)

Rob van Maris

By: Wouter van Reeven Mon, 05 Dec 2005 13:22:58 +0000 Jan,

I do not agree with your statement that “If you can generate stuff completely and never ever have to change it afterwards, of course this is faster than manually building the same functionality”. It very much depends on the complexity of both the application that you want to generate and the generator used. For instance, generating a “Hello World” application may very probably be slower than writing it by hand.
Besides that, configuring a generator to generate what you want it to will take a substantial amount of time. In the case of an application generated by JHeadstart on ADF BC components you will need to configure the ADF BC components and then JHeadstart to get generated what you want. If you misconfigure any component in this process, you will have to go back, reconfigure and regenerate.
With a complex technology like ADF (with the sheer number of files involved) generating will most likely beat creating all files by hand. But this doesn’t mean that in other situations, coding by hand may very well beat generation.

Wouter van Reeven

By: Lucas Jellema Mon, 05 Dec 2005 12:05:44 +0000 Jan, thanks for your reaction. I am not quite sure though what your point exactly is. If and when JHeadstart would be limited to a very narrow range of UI widgets and application flows, and I would have picked the only one it really excels at, you would be absolutely right. And if JHeadstart would not allow you to extend what is generated in a simple way, you would be even more right.

However, and I take it you are well aware of it, JHeadstart generates a substantial number of different UI controls, different page layout and support many different flows to unlimited nested levels.

Besides, the generated code is completely visible and can be seen as the code manually developed by your colleague who had a productive week while you were away skiiing somewhere. What I am trying to say is that JHeadstart provides enormous functionality in many aspects of data oriented applications and only needs manual complements in some.

I do not need to gear my demo towards JHeadstart in order to get superior productivity. Perhaps it is time for a real RAD race, not a virtual one…

By: Jan Mon, 05 Dec 2005 10:13:21 +0000 I think this: “And I happen to know this requirement fits JHeadstart very well – it can be generated completely!” says it all. If you can generate stuff completely and never ever have to change it afterwards, of course this is faster than manually building the same functionality. This is true for JHeadstart and for any other generator tool.