JDeveloper Vs Oracle APEX

In the case if you haven’t followed the discussion about “JDeveloper Vs Oracle APEX” on some of the APEX blogs out there.

How did all start?

Chris Muir, did a posting about “A career path for Oracle developers – consider JDeveloper!” some days ago. It contained some statements with high potential for a nice discussion 🙂 For example that “real” developers who want to make big money and want to learn the “new” concepts “introduced” by Java should look at JDeveloper and not for example at Oracle APEX, because that’s not good for your career path.

His statements produced some echo in the APEX blogging scene. First John Scott wrote a reply posting on it, titled “JDeveloper versus APEX?” and a little bit later another follow-up by Dimitri Gielis titled “We shall not use APEX!?“. And as you can see from the comments on all three articles and a forum posting in the OTN JDeveloper forum, a discussion has started.

I haven’t posted a comment on one of the blogs yet. I first wanted to look how the “fight” about the pro’s and con’s is going on. Hmm, I still remember the good old time “IBM OS/2 vs MS Windows” – BTW, I was part of TeamOS/2 🙂

Just a quick statement from my side, I will write a real comment on Chris article.

[…] 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 […]

I think he is referring to the design patterns of the “Gang of Four” and he also mentions the MVC pattern. To my knowledge they are not specific to Java or .Net, … Most of them can also be used in other languages like PL/SQL. Or the MVC patter about separation of User interface and Business logic. I can’t speak for other Oracle shops, but haven’t we always written PL/SQL packages for our business logical and just called them in Oracle-Forms or in a batch job? So what is the new concept here? Sure a lot of developers just put there code into the Oracle-Forms triggers and mix UI with business logic, but so can you also do in a Java environment. Just look at the first JSP/servlet Java projects. Good software architecture has nothing to do with a development language or a platform!

But one thing I want to mention here is that I have sometimes the impression of some “Java guys” out there (not Chris) which misinterpret some of the design/architecture patterns and who create “(database) independent” code/applications just to satisfy the technology, but without any business need.

They start to create several layers of interfaces/code between the Java business logic and the database, just to be able to say “My application is database “independent” and I can replace Oracle with XML files.”. (I don’t mention here that real database independence is really hard to achieve, just think about read consistency or locking).

I probably would understand that if you are doing product/tool development which you want to sell for different databases, but I suppose most of the Java development is done In-House. How often have you seen that the database is changed during a project??? So why all this interfaces/abstract classes/DAO’s, … (one time I counted 5 different java files/layers/interfaces/abstract classes for an entity object) just to satisfy the design patterns and the “Java” technology?

Why do Java developer tend to re-invent the wheel on the application server and don’t use the existing, proven and fast functionality of the database? I know, because then you are not “database independent”! Don’t use GROUP BY to sum up your data in the database, it’s much more fun pull all the data onto the application server and do it here… 😉

I really have the impression that a lot of code on the application server is just there to satisfy the technology or the next (Java) “hype”. But what is the result? Complex architecture, lot’s of code and unmaintainable applications… Could that be one of the reasons why Java projects sometimes tend to take a little bit longer than supposed? 🙂

Ok, my comment got a little bit longer and it’s just one area which I covered 🙂

Now my final question. When we develop an application, do we want to spend our time at satisfying the technology or do we want to solve business problems? I think APEX helps me to concentrate on the business problem. What do you think?

4 thoughts on “JDeveloper Vs Oracle APEX

  1. I develop allergic reactions when people start shouting that product A is better than product B. Better for what purpose, would be my question. I do not have much knowledge of Java implementations, and more than a bit more knowledge of Apex, but there is one thing that I do know: every customer need is different and you need to do some research first before you advise to implement product A or B (or C). And the suggested superiority of one product is not an argument.

    Is a hammer better than a screwdriver? I’m not sure, depends on what you want to achieve!

  2. In response to Patrick Wolf’s comment:

    MVC is actually way older than the Gang of Four’s writing, and harks back to the days of Xerox Labs in the late ’70s. It took prominence in SmallTalk, but certainly became very popular with the Gang of Fours Design Patterns book published in mid ’90s.

    MVC supplies many benefits, just too many to go into. Best to read the book I guess.

    You’re right that naturally
    good traditional Oracle Forms programmers leaned towards MVC style programming. Did they have a name for it though? I never met a Forms programmer who said MVC to me. And did you ever work on a Forms project where the programmers hadn’t done this? I’m sure the answer is yes because on a number of Forms sites I encountered horrible messes where the programmers has sprayed code in the db and Forms. Great way as a consultant to make money fixing problems, horrible for the maintenance and ongoing cost & complexity of the system.

    Whether the logic should “all” go in the db or midtier is a separate discussion and has been argued strongly elsewhere on the internet already. I’m not going to argue either, but Paul Dorsey who is an advocate of the db and JDeveloper argues all in the database as per his discussion here. I’ll leave you and the readers to decide what is best, I’d rather only start 1 major debate a week 😉

    Leading on from MVC though, your comment “Good software architecture has nothing to do with a development language or platform”. Strong words and incorrect. A good language/platform can help promote good software architecture, because the architecture is built in. JDev’s ADF BC/Faces (a’la MVC) approach forces the programmer to become aware of the division and give it credence. The whole Ruby on Rails framework is built on MVC, and so was SmallTalk. But I think what you meant to say and I’ll agree with, regardless of the language/platform, it is always possible for programmers to make a mess of it.

    I will also agree with you that the traditional Java guys did seem to get things massively wrong by putting a h3ll of a lot of the business and data processing logic in the mid-tier. Q: Did it perform A: Nup. As was “rediscovered” by the Java crew, databases are just a tad better at processing data, something about 20 years of optimisation built in I believe.

    That’s what’s really cool about the JDev approach though, where I, as a traditional PLSQL programmer, can still put the logic that needs to go in the database in PLSQL modules, and via the ADF midtier make calls to it. Neither my SQL or PLSQL skills are withering because I can still work with that handy old Oracle database. But at the same time I can leverage all those Java APIs that provide so much extra functionality.

    (And before you argue that the same functionality is available in the db via PLSQL modules, my recent experience with the new added packages in the db is they are wrappers on the Java equivalent)

    Finally I’ll pick you up on the last paragraph and I’ll speak anecodetally. When writing a JDev solution with ADF (not necessarily a vanilla Java solution as such), do I focus on the business problem or the technical solution? With the older versions of JDev, particular 10.1.2 and earlier that utilised UIX, definitely the technical and it was frustrating. However with 10.1.3, the delight has been the ability to focus on the business problem. Not to say there aren’t technical problems, but these days I’m enjoying writing requirement specs and design specs that I know I can implement in JDev’s ADF rather than tearing my hair out.

    Final final note (I promise), Patrick as noted on one of my other posts, I’m willing to take this whole discussion off board and write a blog post with input from us all, with the goal of writing something that is a tad more clear than the comments sprayed across the several blogs & forums. Please feel free to join me and others in this discussion be emailing subs/@/ccmlabz/net. My feeling is there are other Oracle programmers out there still sitting on the fence who would like to make an informed choice based on our experiences, and not just the Oracle marketing collateral.

    Thanks for taking timeout with the followup post. It’s been great reading the Oracle blogs more recently for a healthy debate.



  3. At the end of the day (and I’m sure Shay would echo this…) JDeveloper should be considered an IDE. The best tool for the job is your trained brain… not a tool with a bunch of wizards. And especially, not proprietary ones.

    IMHO, forms/reports/PL/SQL developers have about as much chance of moving to any enterprise OO platform like JEE or .Net as VB6 developers have of moving to C#. But… Oracle is sure trying to make it look easy with wizard based proprietary solutions!

  4. Not to state the obvious, but APEX is a RAD tool. RAD tools will always have their place in a developer’s toolkit. But you need to pick the right tool for the job.

    Saying that enterprise Java is too complicated/convoluted is just as bad as saying that APEX is too simplistic. But developers seem to get into these religious debates all the time.

    That’s why the developers in my company have all their implementation choices reviewed before they start on any project. Seldom are they ever objective about tools, and often they pick the wrong one for any particular job.

Comments are closed.