Saturday 31 March 2007

A career path for Oracle developers - consider JDeveloper!

Are you considering your career path in the Oracle core technology arena? Missing 1/2 a brain? Then consider a career in database administration (haha, only joking, really, I have plenty of DBA friends and they all have more than 1/2 a brain ;)

Or are you a traditional Oracle Forms or Reports developer who shies away from DBA work because you think DBA work is dull (haha, no really, I'm only joking), aren't actually scared of users (still a joke, I kid you not), and think optimisation is something left for, well, who cares?

The problem for traditional Oracle developers, for those actually concerned about career development while remaining a developer (and by this I mean you have aspirations to stay a programmer, become a top notch developer, you're not retiring soon, you don't want to become a manager, or worse yet, a DBA (seriously I really am joking)), is where do you go from here, given the traditional development areas are dying (ie. Forms & Reports), while sticking in the Oracle core-tech area, where all the big money and good looking people are?

(Alright, I'm being discriminatory to DBAs in this post, but a little fun never hurt anyone, except my DBA pals who get this all the time ;)

As far as can be made out at the moment, traditional Oracle developers have the following avenues to go down:

0) Convert to the dark-side and learn .Net or Ruby on Rails

1) Don't learn anything knew and retire using traditional Oracle development tools like Forms.... knowing good and well that Cobol programmers are now rolling in cash, so you will too (anybody actually ever encountered a rich Cobol programmer?..... oh, and, is, um, willing to give me some cash?)

2) Application Express aka Apex aka HTML DB aka mod_plsql with flashy bits and yet another respository

3) JDeveloper with ADF Business Components and ADF Faces

(oh, and maybe #4, XML/BI Publisher - which I'll leave out of this discussion)

Let's investigate these options.

#0, ah, no, that's an entirely different post.

#1 assumes that the Oracle Forms world is dying. Actually, it's not, but don't expect anything exciting to happen in the Forms arena any time soon. Are you happy extending existing Forms systems, like a safe job, and no interest in learning new stuff? Stick to Forms, though I question why you're in computing in the first place? Have you forgotten the chase .... learning new technologies, making your users "oooooh" and "ahhhhh", making your fellow programmers jealous with tales of the latest technologies you get to play with, the thrill of project deadlines, the thrill of finding bugs and passing those project deadlines, the excitement as the boss shakes your hand and says "Well done Jones" (even if your name isn't Jones)?

I digress.

What about #2, Apex (Application Express)? Weeeeeeeeeell, here's my sticking point with Apex: Apex is too proprietary compared to JDeveloper and is worse for your developer career path. Coincidentally in this manner Apex is just like Forms - and by this I mean have you ever leaped to a new development environment and said - "Ah, this is just like Oracle Forms"? No, well that's because not much else does what Forms does these days - so what you've learnt wont really help you elsewhere. Bang goes the career path with Forms or Apex.

This isn't to say JDev doesn't include proprietary technology, because it does. Lets explain this a little bit more when considering Apex....

If you learn Apex, you will have less of an opportunity to understand and expose yourself to concepts that JDeveloper's ADF makes use of, and in turn the principles that ADF uses that are used elsewhere in computing and are considered good software practice. Or in other words, JDeveloper's ADF will provide a higher educational stepping stone away from the old Forms market than Apex will, as it will teach you new languages, expose you to concepts of design patterns and software architecture, give you a better ability to compare technology X and Y, and might even make you a nicer person (didn't happen for me, but you never know).... and thus (drum-roll please) provide a development career path too.

Why? JDeveloper's ADF is based on something called the MVC design pattern. This software architecture pattern is used heavily in 3-tier based systems (MVC is non existent in Forms) and among other technologies (including Ruby on Rails if we want to name a buzz-world compliant language/framework), and is used within the J2EE world for building enterprise scale applications (and remember, most of the work in the Oracle arena is in enterprise apps, not dinky little apps running standalone on a PC).

The key to the MVC architecture is that it allows us to build and swap-in separate technologies to deal with the model (ie. the persistence API that talks to the database), the view end (ie. the UI technology such as JSF, ADF Faces, Swing etc) for rendering the user interface (UI) and controller technologies (simplistically the bit that co-ordinates the M and the V).

For a Forms programmer moving to the JDev ADF world, the developer is encouraged to use ADF Business Components, and ADF Faces. ADF BC is a persistence layer technology, and ADF Faces the UI side. It all fits together in an MVC pattern.

Now once you've been exposed to 1 set of Model or View technologies, be they ADF BC and ADF Faces, you'll become rapidly aware of other choices. For example in the Java world, there are several other choices for persistence layer technologies (the Model layer), including Hibernate, Toplink, EJB and so on. The thing to realise about all these technologies is that a) there all attempting to do the same thing and b) they all have to solve the same problems. With out a doubt c) some do this better than others..... and in time Darwinism will take hold and leave us with the best-of-breed.

As you become more proficient in Java, and look at these other technologies, and even non-Java based solutions, you start to ask some really tough questions of new emerging technologies..... is it stateful or stateless? Does it provide failover? Can it scale? does it handle the browser back button? can it plug into our SSO services .... and so on .... (Don't know what I'm talking about? Turn to the JDeveloper side my apprentice ;)

One of the other career benefits is, unlike if the Forms or Apex market dies, if one of the technologies you've been using in the JDev sphere (or Java sphere) is quickly superseded by one of the other players, say ADF BC falls to EJB 3.0, at least you're knowledge isn't so heavily wrapped around a proprietary solution, and you don't get the sack.

The beauty too, is once you're at this level, you're no longer just a simple old Oracle developer, you're way on the right track to become a hot Oracle programmer who will be directing projects at your organisation, driving hot cars, and making a fortune on the stock market (well, 1 out of 3 ain't bad).

Surely this has got to be better than being a DBA, Forms or Apex programmer for the rest of your (programmer) life ;)

[This post was inspired by Grant Ronald's recent post What is faster for development: Oracle Forms or JDeveloper? Grant's article is a great one in telling you how simple JDev programming is becoming.... but I wanted to consider besides the technology "why", from the developer's career path, you should consider JDev]

Epilogue: Oracle developers should also carefully consider JDeveloper as there has been many comments that Oracle's EBS v12 and the whole Fusion stack will use JDeveloper technologies. The point being is if you're organisation uses these technologies and you are tasked to extend them, JDeveloper will be the tool that you use to do these. I've not been exposed to either of these technologies (EBS v12 or Fusion) so please take this comment with a grain of salt, unless somebody is willing to post a link to any webpages that prove this fact.

Epliogue x 2: The other purpose behind this post is to start discussions about which *is* better, JDev + ADF or Apex. Currently Oracle is IMHO being "Mum" about this. Given that there are dozens of bloggers now selling, um, promoting Apex and JDeveloper, what about their thoughts on which is they way to go?.... with consideration from all sorts of angles like scalability, skill sets required, failover support, ease of development and so on.

24 comments:

Brian Duff said...

Excellent blog entry, Chris :)

I don't think it's any secret that a significant amount of Oracle's technology stack is being built using JDeveloper and ADF... A primary focus of the release of JDeveloper we're currently working on is on teams in the Applications division building Fusion.

Unknown said...

Chris,

Interesting post...however I must respond to a few points you make.

First up, my disclaimer, I'm heavily into APEX development hence my 'bias' will show, however the 'bias' is not simply because I *think* APEX is superior , it is because I know what it is capable of. I have used a great many different tools in my career to date and APEX is just one of those tools, it is however the tool that has been ultimately the most productive one I've ever used.

>Apex is too proprietary compared to JDeveloper

Proprietry in what way? APEX runs within the Oracle database sure, so you can't take an APEX application and run it in MySQL or MSSQL, but then I wouldn't expect to be able to take my PL/SQL code and run it in MySQL or MSSQL either.

APEX runs inside the Oracle DB, it is specifically an Oracle development tool. I don't see the 'proprietry' thing an issue. Unless you're talking about the fact that you don't have access to the APEX sourcecode for the tool itself? But then you could make that point about a great deal of tools out there. Having access to the sourcecode is *possibly* better than not having access to the sourcecode. However ultimate (I think) it's better to have a tool that does what you want it to, rather than having to 'modify the source code' yourself to make it do that.

>and is worse for your developer career path.

Wow, anything to back that up? How is it *worse* for a development career path? Sure the APEX job market is smaller than many other. However there are fewer APEX developers too (smaller fish need a smaller pond).

Plus, in that statement you forget one of the *core* aspects of APEX. With APEX you are not learning 'another' development language really, you are ultimately using SQL, PL/SQL and Javascript. With a knowledge of SQL, PL/SQL and Javascript I would say any APEX developer has a potentially *massive* client base.

>If you learn Apex, you will have less of an
>opportunity to understand and expose yourself
>to concepts that JDeveloper's ADF makes use of

But equally I could argue 'if you learn JDeveloper you will have less of an opportunity to learn APEX' so I don't really see the point there?

Do you believe there are no concepts involved in Oracle SQL, PL/SQL programming? If that were true why do we have books by people such as Tom Kyte and Steven Feuerstein?

Please don't make the mistake of thinking that APEX is 'just a toy GUI tool', underneath it lies the full power and capabilities of the database. Of course there are people using APEX who need it for nothing more than creating the odd report or form, however there are many of us using it for full enterprise systems.

>JDeveloper's ADF will provide a higher
>educational stepping stone away from the old
>Forms market than Apex will

Again, can you back up the statement 'higher educational stepping stone'? I am not sure how you are qualifying that statement? What is that based on? What justification do you have for that statement?

>and remember, most of the work in the Oracle
>arena is in enterprise apps, not dinky little apps
>running standalone on a PC

Yes..and Oracle recently rewrote Metalink in APEX, so they obviously believe it is an 'Enterprise app' capable tool.

>expose you to concepts of design patterns and
>software architecture

Equally true with APEX, absolutely 100% true that you can learn design patterns and software architecture with APEX. If you disagree then you are also disagreeing that you cannot learn design patterns and software architecture with PL/SQL...is that what you believe?

>Does it provide failover? Can it scale? does it
>handle the browser back button? can it plug into
>our SSO services

APEX runs within the database, so it scales as you scale your database (and OHS/IAS where applicable). Yep it can handle the back-button (which is no different to any other website really), can it plug into SSO? Yep absolutely.

>One of the other career benefits is, unlike if the
>Forms or Apex market dies

Ahhh, the old argument. I've heard this one many times (with many different technologies used as an example). APEX runs inside the database, so essentially you're saying Oracle would need to decide to drop using their database product?

Are you aware that Oracle now ship an APEX installation in the database? Are you aware of the XE database edition which by default provides an APEX application environment out of the box?

What makes you believe that APEX is any more likely to be 'dropped' than JDeveloper is?

John.

Carl Backstrom said...

Hello,

Well I would be even a bit more 'biased' than John on this one considering I'm on of the APEX developers.

But this statement

>and is worse for your developer career path.

sounds a bit like FUD http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt to me, as an active APEX community member we constantly reiterate that in the end of the day all APEX (or any other web development environment for that matter) does creates is web pages.

So if you look at the core technologies it takes to create a fully customized APEX application there is
SQL , PL/SQL , CSS , HTML , Javascript only one which is Oracle specific. I would say that if you have decided to be a web application developer as a career learning or using any of these can't be bad for your career path.

As for

>>
The other purpose behind this post is to start discussions about which *is* better, JDev + ADF or Apex.
>>

I'm not going to get into which is 'better' , I'm still too deeply embroiled in the emacs vs vi debate, but I definitely have ideas of which is 'easier'.

Take this example here of setting up AJAX based pagination on a report in JDeveloper http://www.oracle.com/technology/products/jdev/howtos/1013/icefaces/jpaicefaces.html and how many steps it takes to enable compared to the steps to do that in APEX

1. Log into your Workspace.
2. Create a SQL report.
3. Apply the AJAX enabled report template.
4. Enjoy

Yup thats it, it's that easy and you also get AJAX based sorting as a bonus.

Past that I guess I've always been in the position (and plan to stay there) where my career depends on the knowledge of technology I have and not the particular IDE I use.

Carl

Scott said...

I'll throw in my $0.02 regarding this line:

> [APEX] is worse for your developer career path.

As the founder of a company specializing in APEX, I've got to disagree. I've had tremendous success using APEX as a platform, and I have learned more about the Oracle Database in the last couple of years than ever before. That's because APEX makes the common tasks so simple, I can focus on what the clients really need - someone to actually listen to them and deliver a system which solves their problem.

APEX gives me a simple, slick platform in which to do just that. It's trivial to install, and even easier to prototype a real application while sitting with the client.

Sure, there are probably more jobs that demand JDeveloper & ADF skills, and if that's the metric which you are using, then perhaps you should state that.

However, by learning APEX & the Oracle Database, you are by no means limiting your career path or skill set.

- Scott -

Dimitri Gielis said...

Hi Chris,

I love to work with APEX (hence; I'm an APEX Evangelist).
I agree ofcourse with John, Carl and Scott ;-)

I also belief there's a place for both environments, but if you really want to have a "test" between some development environments... here's a link to a Dutch site who did the comparison: Game (in Dutch).

If you don't understand Dutch, the conclusion was that APEX won the match!

I'l probably go in more detail about this on my blog soon.

Dimitri

Chris Muir said...

Hey gang,

Firstly thanks very much for taking the time out to respond to my post. Personally I think there has been little discussion on where traditional Oracle developers should focus their learning efforts, thus my post. With the current Oracle marketing collateral it's hard to know which avenue is best as they are both marketed as the beez-kneez, so a debate like this where you put forward your true earned experience is a valuable one for all the other readers out there who are still stuck at the starting post.

Given that the Apex respondents all took time out on their weekend to reply shows dedication to the tool I guess (ok, I'll admit I was a nerd too and read your responses on Sunday ;) Most of the JDev guys were probably recovering from their headaches.

When I have time I'd like to address some of your points. In particular I'll agree with the point some of you made that the learning curve on Apex is easier, and the ability to be productive earlier (as compared to ADF or other techs) is possible (especially for ex-Forms programmers). I don't disagree with this and I'd like to take this point further and consider the issue of cost-benefit-analysis for the organisation.

I'd also like to address my proprietary comments in a little more detail, as I was obviously shot down without backing up my facts (ok, ok, I wrote that post on a plane trip returning from NZ where I'd been asked which was better and I honestly beyond my own experience couldn't comment on any good discussions I'd read anywhere (and my Dutch just isn't that good) and wanted to see some debate on the issue - thus the post).

I note no comments from JDev evangelists yet beside Brian Duff. Hopefully they're not all ducking their heads (I have a habit of starting these sort of discussions then being left high and dry ;). However given the Apex corner's replies, it would seem there is no reason to go with JDeveloper and ADF. That can't be true can it.... or is writing EBS 12 & Fuson in JDev just a big mistake on Oracle's part? Should they have done it all in Apex instead?

So, very much keen to hear others' thoughts on the JDev vs Apex debate.

Oh, and Carl, obviously vi is better ;) (yeah, yeah, s*cker for punishment)

John, thanks for the cross post. Very much interested to hear your thoughts.

I promise at the end of this discussion to write a summary post of all people's thoughts.

This all sounds like a fantastic idea for a panel session at the next OOW to me!

CM.

Chris Muir said...

PS. Anybody willing to give a translation of the Dutch website, if not the whole article, just the conclusion please? Babelfish just doesn't give it justice I'm afraid.

Kris said...

Personally I get paid to implement a solution, using the best tools for the job. One thing that I think is apparent is that Apex helps companies leverage their investment in Oracle and IP in SQL & PL/SQL without having to re-invent the wheel every time they want to make a CRUD (Create, Report,Update,Delete) application.

ADF and JDeveloper are also a very nice ways to go about a development, but if your development team's experience lies with SQL & PL/SQL it really isn't going to pay dividends.

My opinions also echo the sentiments of Carl, John, and Dimitri. I've seen this type of argument used so many times in the Linux world with KDE vs Gnome, Windows vs Linux, Linux vs Mac. All are still going strong and I think it is courses for horses.

Chris Muir said...

Or courses for horses hey Kris? ;) Thanks for your reply.

Actually it seems to me the Apex supporters will argue it's easy to leverage SQL/PLSQL to create CRUD apps in Apex, and the JDev ADF BC/Faces supporters will argue exactly the same thing. Personally I leverage both SQL/PLSQL in JDev, and I find CRUD apps pretty easy to mass produce. Hooking SQL/PLSQL is fairly trivial IMHO in the JDev world, and as you indicate it is also easy in the Apex world. So as you say I don't really think either wins with this point in mind.

Lets take this a little further. Note the following aren't criticisms, just discussion points.

Taking up your other point, does it all come down when picking ADF over Apex, to an issue of leveraging skillsets? Is Apex better suited to SQL/PLSQL teams, while JDev suited to possibly those with a Java background? Thus as a Forms programmer with the former, Apex is the key?

This exact opinion (one of skillsets) is one that I've read elsewhere and surmised with a colleague yet again a few weeks ago. Is it really just as simple as this? The choice of either tech is based on your current skillset? Is there a) no reason to learn something out of your box, b) there is no reason to learn ADF/JDev, and c) the decision of the programmer to stay within their skill box should always be based around the business's needs and not their own career path?

Or what about, if we end up with a bunch of Apex programmers, but Oracle comes out with the Fusion-JDev enriched environment, its (theoretically) successful, what is the impact on those Apex programmers if they can't extend Oracle's own apps? From Oracle's (false?) marketing point of view OraApps/Fusion appears to be everything. But is there enough other custom development occurring outside this sphere that the Apex market will be self supporting? Is there a belief Apex apps can be intergrated into this future OraApps/Fusion market? Or is it a case of who cares or it's not an issue?

Again just points for discussion. I'd hate to get flamed, so I don't want to be seen to be criticising, but I am interested in constructive comments, and I'm sure others are too.

CM.

Frank Nimphius said...

Chris,

your bog entry has some thunder in it. I think there is no easy telling of right or wrong in comparing APEX with JDeveloper.

There are applications that by their profile are better build in Java and J2EE while others have a profile that speaks for APEX. And there there are applications that are goood for scripting or .Net.

Oracle provides a choice of development tools that developers can use to build applications based on their skill set, the application usecase and lifecycle.

With Forms client-server we had one tool that people used to build everything with - including applications - like self service applications - that Oracle Forms was not designed for.

Imagine the market value of a developer who can build Java/J2EE applications, Forms and APEX.

Even if some of the technologies are Oracle specific, my experience is that not many care as long as the application they have to build is delivered within time and budget.

Like others commenting your blog entry, I am biased because I work on building JDeveloper and ADF. I must admit that I don't know APEX and BI Publisher good enough to be able to give a clear guidance of when to use which technology.

Frank

Ps.: Duncan Mills wrote an article for the ODTUG mgazine (currently in review) that focusses on the same "when to use which technology for what reason" topic.

Dimitri Gielis said...

Hi Chris,

As promised, I made a post on my blog. I also added a summary of the link I posted above, so that would give you an idea what the Dutch text says.

Dimitri

Unknown said...

>Imagine the market value of a developer who can >build Java/J2EE applications, Forms and APEX.

(above quote from the post by frank)

Well, I guess it depends what skills 'they' were looking for. Do they want someone with a broad range of skills, or a specialist in one particular area?

Is it possible to be 'an expert' in JDeveloper (for example) if you are also dividing your time working with APEX and vice-versa?

I have to admit that I've always chosen to specialise in a particular area (such as Oracle or APEX) and to become more knowlegable about those areas than I would be able to if I also tried to cover a broad range of topics.

Now that doesn't mean that I *only* know about Oracle and APEX, I know about other things too, but if I had to 'sell myself' then I would say "Oracle and APEX developer" I wouldn't say "VB, C, Perl, Unix, Linux, Cobol, Delphi, Oracle and APEX developer".

JDeveloper and APEX aren't fundamentally 'good' or 'bad', it is really down to the skills of the individual developers using them. Any developer can code badly, regardless of the tool involved.

Perhaps what ultimately matters more than the tool you use, is your knowledge about how best to use that tool and your professionalism and pride in developing a good solution.

John.

Tonguç said...

For me there was and is and will be only one career path for each "Oracle " developer which is sql and pl/sql :)

But apex enabled us(pl/sql developers-dbas) to develop web based applications in minutes, this was a very unique experience for me; without any pain here you gain :)

No need to have a civil war, with its market Oracle will let all of us to have our "best" career path.

Best regards,
Tonguc

Anonymous said...

http://forums.oracle.com/forums/thread.jspa?threadID=492203

For those who like to continue a SAFE debate.

Anonymous said...

Chris - thats the price you pay for being contencious! ;o)

Personally my view is, you're going to have as much luck with this argument as with "What the best colour for your car". Everyone has their own opinion, there are too many factors that influence decisions (and lets face it if you have spent a fortune on a blue car you probably won't be praising the virtues of anything else) and to be honest, web forums are about the worst place to debate this question anyway..

To try and settle the dust on this, we (Oracle) are publishing a paper about the tools choices...it should be out in ODTUG journal soon (and will also be published externally as well).

My parting shot on this question is always - if you are doing DIY would you argue that its best to have only a hammer, screwdriver or saw??....or would you prefer to have a nice tool belt that holds all three and you choose the best one for the job at hand?

Regards
Grant

http://www.groundside.com

Anonymous said...

Oh Chris, a final parting shot..
"but don't expect anything exciting to happen in the Forms arena any time soon. Are you happy extending existing Forms systems, like a safe job, and no interest in learning new stuff? "

I'm afraid you are way off the mark here - where I see a HUGE demand is for customer who have an investment in Forms and looking to adopt SOA priciples. That means, if you are a Forms developer who knows about web services, BPEL and how to get them to work together, then you are on the gravy train...

I wish we wouldn't get into the mentality of "one tool"...the opportunities if you know Forms/PLSQL and some of the "new" technologies make you a VERY valuable commodity.

Chris Muir said...

Just in case you can't read the link in the Anonymous post above because Blogger has cut it off:

JDev OTN Forum post

Patrick Wolf said...

Hi Chris,

another APEX defender ;-)

I did a posting about your article on my blog. At the beginning I was just going to write a short comment, at the end it got a little bit longer :-)

But to defend JDeveloper and ADF a little bit, at least I think it's the most productive Java development environment of the different Java IDEs.

Why? Because the Oracle guys recognized (maybe because there are some developers which worked in the past for Oracle Forms) that you can only get productivity with declarative development. The other Java IDEs are working at a level to low and in the best case the have some code generating wizards, but that's not comparable to a declarative development where you don't have the hassles of round-trip engineering.

So at least of few good words about JDeveloper ;-)

I still find it interesting that Oracle promised for the last few years that it will make JDeveloper as productive as Oracle Forms. Recently I read an article on Grants blog that they are finally there. My question is now, why did they really spend all this money and resources just to have now the "same" feature set and productivity as Oracle Forms? If you imagine what would have been possible if all that money went into the Oracle Forms development...

Patrick

Anonymous said...

Partick - did I actually said we are finally ther? Does it mean we can put our fee up ;) I don't think I did!

Second point - I've said we should make the development experience "Forms like". We don't have a goal (and I never said we did) of rebuilding Forms in Java - that sells JDeveloper way short!
If you think Forms "have no the same feature set" then I'm afraid that shows a distinct lack of knowledge about Jdeveloper (forgive me if I'm too harsh on you). ;o)

Unknown said...

Hi Grant,
I totally agree with your comment:

"I'm afraid you are way off the mark here - where I see a HUGE demand is for customer who have an investment in Forms and looking to adopt SOA priciples. That means, if you are a Forms developer who knows about web services, BPEL and how to get them to work together, then you are on the gravy train..."

Is forms dead?

I've read the following document:
http://www.oracle.com/technology/products/forms/pdf/10g/ToolsSOD.pdf

In the end of the document it suggests that you must use Forms to maintain your existing applications, and develop new modules ("Self service user interface") using JDeveloper.

But, what happen if you don't have an existing application developed and you must develop a new ERP?

I must develop all the application with ADF? I think that in this case Forms is the correct tool.

What do you think?

Thanks,

Carles Prat
www.bbr.cat

Chris Muir said...

Carles, I think you miss the point about all new development in JDeveloper. It's not about JDeveloper as such, but rather what you can deliver to your business.

With JDev ADF or Apex or PHP or whatever web technology I can deliver a system that I don't have to do client installs, I can easily deploy on the internet with the associated connectivity benefits, I can make parts of the application easily accessible to both my staff and my customers.

Think about a Forms install. Typically LAN constrained, you wouldn't deploy it to the internet, you'd need separate systems for your customer/web facing systems and your staff.

So the original point stands. Maintaining and extending existing Forms sites is best done with Forms. However new system development should not limit itself to the Forms box because the world has moved on from client/server development.

Cheers,

CM.

Unknown said...

Hello there,
Just a single question about what would be the best. Is it something that customers buy and use? If yes, could anybody, here, tell my how many (serious) applications are built with Jdev, then Apex, thand finally Forms?
Francois

Chris Muir said...

Hi Francois

Hmmm, that doesn't seem to be a single question to me.

All 3 are used. Forms has the largest install base, but has been around for 20 years or more. Apex is used extensively by many organisations including Oracle itself on Metalinks. JDeveloper: its previous tech stacks have been used in tools such as OEM and EBus, and its latest tech stack in such things as EBus r12. Serious enough for you? It really depends by what you mean by "serious".

As for exact numbers you have to ask Oracle about license sales. I'm not privy to that sort of information.

Regards,

CM.

Unknown said...

Thank's Chris.
By "serious", I mean companies that use the tool to do their real business, and not only for a "demonstration" purpose. I was just asking the question, but I do not have the answer either ;-)
As Grant said so many times, the best tool is probably the one that suits your need and also suits your skills.
If you have a Java team, Forms and Apex are just the tools you don't need, but if your skills are PL/SQL oriented, JDev would be something so bizarre... ;D
Francois