Tuesday, March 11, 2008

The war debate continues...

I managed to get my hands on a copy of an article put together by Chris Muir with contributions from some leading names in Oracle development tool circles. The article attempts to shed light on which development tool is the best: JDeveloper, Apex or Forms.

The article stands out as a nice centralised scoring system for basing a decision on which tool to use in different application environments, although there is no direct comparison outlining the disadvantages of using each of the tools.

Each of the tools contains a write-up of their capabilites with gradings given on a set of 9 explicit categories, and a score for each category is given out of 5.
I noticed that all of the advocates of the tools made a point that each of their respective products could provide a workable application in "just a few clicks", but that at some point a typical developer would have to get down and dirty with some real coding to apply some complex business rules.

So it seems to me that it all comes down to realising the actual capabilities of each tool, but the main driving factor would be the comfort the developer has in using the extension language associated with the tool - be that SQL, PL/SQL, Javascript or Java. Once you have enough experience with the tool and - more importantly - the extension language set, the capabilities of the tool open up more possibilities.

When this point is realised, you can then work out where to apply your development crew. Clearly, since you are going to be working with an Oracle database, you would expect your developers to already have SQL and PL/SQL skills. But, if you want them to produce amazing applications, you also want them to specialise in the extension language. Now, what do think is more likely - Javascript or Java?


Noons said...

Cool blog entry, Marc.

Javascript, of course. In the context of the "amazing UI".

Java can only produce "amazing applications" - I presume you meant the UI - when its app code is downloaded to the browser, a-la jinitiator from Forms.

Otherwise folks are forever condemned to the hourglass cursor - yes, it takes TIME to download large apps even in 1gbps - or they are forced to cope with yet another brain-damaged MVC "shopping cart UI" with a servlet pushing character data around.

And that is pretty much the nature of the java/j2ee beast: it's an application server-oriented solution, not a desktop-oriented environment.

Javascript is light, does most of what is needed for "amazing UI" natively and with little fuss, using the desktop resources rather than wasting the ones of a very expensive (but "scalable"!) app server.

Now: if we get away from the UI blinking lights and move to real application logic, then java/j2ee has the obvious advantage: it's a proper "elephant gun" for that!

What is the ideal? I still think a mix of the two. With j2ee pushing data to a javascript frontend that does all the niceties, while java can apply serious computing power where needed and pass on to the db server all the data crunching tasks.

Is that the description of an existing architecture, I hear you ask? ;-)

Marc Thompson said...

I think its astounding that everyone still seems to be concentrating on the browser based application. Sure, we have seen the 'evolution' of applications go from client/server to the whole three tier approach, but it seems that everything will eventually go full circle and start trying to leverage the power of the client PC again. If we all have these multi-GHz machines, why would we want to be limited to application code stuck within the confines of a browser?
We are seeing the wheels beginning to turn from Microsoft (with their 'smart-client' applications) and Adobe (AIR).

Sure, if we are measuring Web-based applications then we can discuss the merits and annoyances of Javascript and Java, but then if you start considering that a lot of organisations will be using applications for internal use only, then there is no need to limit yourself to web-based application distribution, nor to the real limitations of HTML based UI-rendering.

In the end, it's all horses-for-courses - the technology you use for application building must lend itself to the desired result and the processes it must cover.

Chris said...


I work for an ISV, we've built our main application with forms, started with 4.0 and now are stuck on C/S 6i because of the license costs. That stupid app server costs nearly as much as our application, which is pretty hard on sales.

As I see it, forms is too expensive and neither APEX nor ADF are suited for heavy backoffice data entry. Ever tried to put more than one tabular form on an APEX page? See what I mean. So, while I enjoy the fight, the whole APEX-ADF war seems to be between frameworks that are built for someone else.

Marc, you mentioned smart clients. I see that movement, too. Nevertheless, there is not very much you can't do in plain javascript and html but you avoid yet another vendor lock-in. I encourage everybody to google Tibco General Interface, for example.

So, because the alternatives stink, I'm doing the most unprofessional thing, i.e. do it myself. I've built a prototype of a javascript and pl/sql framework with the look and feel of forms from scratch (with no java in-between, Nuno ;-)). It's still a toy, but surprisingly much is possible with 800 lines of javascript. I'll probably post when there is a minimally usable version.

Anonymous said...

I don't fully understand your point on "JavaScript or Java". You'll want to know JavaScript for both APEX and J2EE applications if you want to build-in client-side interactivity or AJAX components. Both tools are starting to do some of that for you, and will continue to extend this functionality.

Marc Thompson said...

I agree that the new techonologies and frameworks being promoted seem to complicate situations where they don't really need to. A lot of it comes down to sales pitches and counting the incoming dollars. But, there are also the elements of efficiency and flexibility. The new technologies are being developed and widely used because they allow an application to be expanded beyond a fixed number of users in a single fixed location. The speed and pervasiveness of the internet, tied with the globalisation of corporations, means that the presence of an application needs to be spread out to a wider location, and to a larger number of users.
That is where the scalability of J2EE applications come into their own.

If your application doesn't require that sort of scope, then, absolutely, the options seem to be closing down, which is a shame.

Your self-built alternative sounds very interesting. I'll keep an eye on your blog to see how it's coming along.

My point was that the main extension language that is used for JDev/ADF and APEX is Java and JavaScript respectively. For complex applications, you cannot develop an ADF application without Java, and you cannot develop an APEX application without Javascript. Sure, you can throw some JavaScript into a J2EE application, and you could probably access some Java code from APEX (I'm sure someone has done it), but they would not be the main languages used for the majority of coding within that application.

hotAndCode said...

This is what I dislike most about Oracle. Within its own ranks it has these technology wars. I realize this happens with other companies but it seems more pronounced with Oracle. 1st we had jdeveloper verses Forms. Now its Jdeveloper verses APEX. Reminds me of the Windows verses OS/2 wars, but it least that was between two separate competing companies. I strongly believe these wars are a reflection of what is happening within Oracle itself, between its Java programmers and its traditional PLsql programmers. Oracle needs to position its products provide synergies which will allow each to exist without threatening the other. At the very least, the position of each of its development products need to be more clearly delineated. Like I said before the technology wars are more pronounced with Oracle. For example, I believe, all of Microsoft's languages work within a single development environment --visual studio .net, and each language runs within single VM. Why not incorporate PLSQL and APEX development within Jdeveloper? This would have help to end the PLSQL/ Java war. As a result some oracle shops with have to decide which developers to keep and which to let go-- Java or PLsql. Are Microsoft developers happier then Oracle’s? Are Microsoft developers more comfortable with the investment of time and money they spend becoming proficient with its (microsoft's) development tools? Im not a Microsoft developer, but I’m strongly considering becoming one. As Oracle developers we should not just sit back and let oracle cloud our career paths by pitting one type of Oracle developer against another. This Jdev, verse Forms and now Jdeveloper verses Apex wars are unnecessary. Better product planning and coordination between Oracles development tools groups could have made life easier for us. Let start a internet petition letter demanding better synergies between these tools!!!

Can't we just all get along.

Marc Thompson said...

I agree with the dilemma you are seeing. Oracle seems to be quite clearly divided in the approach they are promoting for the sake of their future development environments.

But, I think, at the same time they are trying to mature each product in a specific direction, and this is taking time; maybe time that they can't afford.

You could argue that Microsoft itself has undergone the same split - they have 3 directions with VB, C++ and now C#. Now, they are all tied together under the .Net Framework banner, but they each have their own targeted developer and application audience.
Oracle has its own internal agenda as to where each of its tools is to be targeted, and there are the 'evangelists' outside of Oracle who will talk up the advantages of their chosen preference.

I reckon we can all get along, but does that mean that we ourselves should start casting dispersions? This ain't no religion, so we can always feel free to use any development tool that fits the desired outcome and skill-set.

The synergies will come as the tools mature - so far, we can only view APEX apps in JDeveloper, but given time, JDev might just expand to encapsulate Apex developement as well... we shall see.