This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm in the midst of building a professional roadmap for my University's PL/SQL staff. Is it necessary to learn JAVA before a developer can grasp Groovy? Would a 'Complete Groovy Training-type course' be a reasonable first start to transtition a PL/SQL developer to an O-O language?
Well, I'm an ancient Oracle developer with some Java (SCJP, a year of J2EE and EJB), plus a little bit of Groovy/Grails, so I've made a similar transition to some extent.
I reckon that if you're going to be using Groovy generally, you might as well get your Oracle people learning Groovy first. It's easier to pick up, it's more fun, and it's far less of a flashback to the bad old days of 3GL programming for those of us who remember the pain of writing DB applications with just Pro*C and SQL! Maybe encourage them to explore something like Grails, just so they can experience rapid application development with JVM-based tools.
Of course, in the end they'll still need to learn about Java and JEE and Spring and Hibernate and so on, but no point paralysing their souls with all that stuff right at the outset. Also, learning how to do things the Groovy way may encourage them to make better use of all that Grooviness before resorting to Java if necessary, rather than writing more or less pure Java but pretending it's Groovy. Groovy is also useful for ad hoc scripting tasks, while still having access to the power of Java libraries at the same time, which gives people more opportunities to make use of their newly acquired Groovy skills.
Incidentally, I would expect most experienced DB developers to find the basic concepts of OO relatively straightforward to pick up, because we're already used to thinking about data+behaviour more coherently than a pure 3GL procedural programmer, for example. And Groovy feels much more consistently OO than Java anyway.
Anyway, that was my own experience of making that transition. Hope this helps - sounds like an interesting time ahead for your Oracle staff!
No more Blub for me, thank you, Vicar.
Joined: Mar 31, 2011
Thank you very much for your insightful response. Your feedback has given me a sigh of relief and confirms my 'hopes'. Sincere thanks! ~n
This is probably blasphemy to the good citizens of JavaRanch, but it sounds like you probably have a lot of existing investment in PL/SQL code. I don't know what your organisation's longer term plans are, of course, but I would be very cautious about assuming it is either possible or desirable to move a lot of this kind of data-centric functionality out of the database and into an external 3GL, unless you are actively planning to abandon the Oracle platform entirely in the near future.
There are a lot of good reasons to keep this kind of "data-conscious" processing close to the data, in terms of making efficient use of your network, the database (your relational virtual machine) and the massive functionality it provides and for which you've already paid handsomely. In my experience, the general rule of thumb for data-centric processing on Oracle tends to be along the lines of Oracle guru Tom Kyte's recommendations i.e. if you can do it in pure SQL, use SQL. If you can't do it in pure SQL, use PL/SQL. If you can't do it in PL/SQL, try using Java stored procedures. If that won't do what you need, then you'll need to resort to external tools like Java, C, Groovy/Grails etc.
Of course, you wouldn't try to implement a highly interactive web application completely in PL/SQL (well, unless you use Oracle Application Express!), and you can't implement a GUI or a thick middle tier without using something like Java/JEE (or Groovy/Grails) etc. Java and the JVM are immensely powerful and flexible, but sometimes you need to use the right tools for a particular job, and I've seen too many Java/JEE projects struggling to do things in Java that could and should have been done much more easily, efficiently and effectively within the database.
Obviously, your organisation will have its own priorities, resources and requirements. But don't rush to shift processing out of the database unless you need to.
On the other hand, of course, despite being a grumpy old Oracle developer, I'd love the opportunity to work on Groovy/Grails database applications, so I hope your staff will have a lot of fun exploring and making good use of these new technologies!