Job Statistics - Product and Technology Choices for the Future

As a result of looking at Rick Hightower's blog on jobs for Spring and Hibernate - http://jroller.com/page/RickHigh?entry=stack_of_choice_jsf_hibernate - it seemed like playing with Indeed Jobs could almost be as entertaining as a video game (for about 5 minutes!).

It has some practical bearing on IT professionals because if you are working with a technology or product where jobs are rapidly going to zero and you have a family to feed or rent/mortgage to pay, it is good to think ahead. It is also a way to identify up and comers as Rick did with Spring.

One problem I had with Indeed engine was how easy it was to come out with misleading results - using "Spring" brought back jobs in places named Spring versus "Spring Java" which brought back jobs more relevant to Spring developers. "Oracle AS" brought back jobs using Oracle in places named or abbreviated "AS". You yourself may have an opinion or two on whether my take here is valid :-)

Trying to get something that seemed to bring back meaningful jobs by product, framework and open source, I have several possibly interesting graphs to share. I have my particular bias, like Rick did in his survey, of seeing how healthy the technologies and products I work on are from a job creation perspective.

The first is "Oracle Application Server", "WebLogic", "WebSphere", "Tomcat", "JBoss" and "Geronimo". I also wanted to transpose the size of the developer market that these server infrastructures represent against the job requirements for some of the commonly used frameworks and technologies so I added in "Spring Java", "Hibernate", "TopLink", "ADF", "BC4J". Here is what I got:

http://www.indeed.com/jobtrends?q=oracle+application+server%2C+jboss%2C+weblogic%2C+websphere%2C+sun+application+server%2C+spring+java%2C+hibernate%2C+adf%2C+bc4j%2C+toplink%2C+tomcat%2C+geronimo

and inline:


I was happy to see that Oracle Application Server came out on top, followed by WebSphere, WebLogic and Tomcat. JBoss was next and Geronimo at the bottom. Admittedly this is somewhat problematic for all products - e.g. WebSphere is a huge brand encompassing more than the application server and the jobs showed this - calling out WebSphere Application Server like here:

http://www.indeed.com/jobtrends?q=oracle+application+server%2C+jboss%2C+weblogic%2C+websphere+application+server%2C+sun+application+server%2C+spring+java%2C+hibernate%2C+adf%2C+bc4j%2C+toplink%2C+tomcat%2C+geronimo



makes Oracle Application Server and WebLogic the two dominant application server job generators out there. Correspondingly, I could see a slight DBA bias in the Oracle jobs though in general they were pretty reasonably reflective of middleware jobs, frequently being Oracle Application Server Administrators or developers.

The large size of Oracle Application Server users did match what I also have seen at our own events, as skewed as our own event obviously will be. The data point I compare to is unlike 4 years ago, at OpenWorld where we would have 100 people per room on Oracle Application Server sessions, now, this year depending on the topic you could see 300-400 people sometimes many more, particularly if the topic was SOA oriented. While this may have been an unusual event - it was an almost overwhelming event in terms of attendance (I believe about 40,000 people!) literally shutting down streets in San Francisco - it was pretty clear there is a huge community of folks asking about and working with Oracle middleware and naturally there is a matching set of jobs out there backed up by this graphic. An Oracle middleware economy so to speak!

One reason I did the breakout above is to show in terms of job opportunity, it appears the bulk of the jobs still fall into knowing the overall product offering versus just the technology. It is one thing to know JSF or EJB, it is another to be successful on a specific application server. Clearly you will be miles ahead knowing the technology, particularly standards based or defacto standards (ala Spring) but employers will frequently hire you on your specific product domain experience (e.g. I know how to cluster Oracle Application Server in a highly available infrastructure, versus I know how to build a servlet that does state replication - two related but different tasks).

Let's dig down in the mess of technologies at the bottom of the above graphic, hidden by the jobs in the server space, so like Rick, we have a better sense of job requirements in the underlying technologies that the upper level application servers support. Here the same thing can be illustrated but I added in JSP, JMS, servlet and EJB to see where these old stalwarts live in the minds of job recruiters:

http://www.indeed.com/jobtrends?q=spring+java%2C+hibernate%2C+adf%2C+bc4j%2C+toplink%2C+jms%2C+ejb%2C+ejb3%2C+jsp%2C+servlet



The interesting thing here is those old fashion baseline technologies of Java EE - JSP (the top orange line -- by far above all others), EJB (purple) and JMS (yellow)- still are the largest job requirements out there beyond these emerging frameworks - they are, so to speak, the meat and potatoes you need as a developer (the SQL of middleware).

Going one level deeper into Rick's analysis, there is absolutely no doubt that Spring, Hiberate and JSF, while the next level down, seem to be emerging into baseline requirements for developers to know for technology jobs. I think it is reasonable to conclude they are the meat and potatoes of the future:

http://www.indeed.com/jobtrends?q=spring+java%2C+hibernate%2C+adf%2C+bc4j%2C+toplink%2C+jsf


The next one I thought I would check out as EJB 3.0, JPA, OpenJPA, TopLink Essentials (the reference implementation for JPA persistence in the Java EE 5.0 Sun reference implementation as well as the JPA persistence provider in Oracle Application Server). They were hidden in the noise in the above graphic, possibly indicating they are still battling it out for mindshare and job requirements:

http://www.indeed.com/jobtrends?q=ejb3%2C+jpa%2C+openjpa%2C+ejb+3.0%2C+toplink+essentials



The numbers are substantially smaller but it is pretty clear since EJB 3.0 finalized several months ago and JPA has become a recognized term for persistence, there is a clear upswing. I suspect in 6 months to a year - particularly if I judge by the volume of e-mail and customers I get around EJB 3.0/JPA, we will see EJB3.0/JPA merge with the other three technologies - Hibernate, JSF, Spring.

It wouldn't be fair if we didn't do the old fashion .NET versus Java survey so here it is. I never know what is more valid in terms of comparing because recruiters lump languages with runtimes but for reference I did .NET, J2EE, Java, C# and PHP.

My personal conclusion based on reading the job descriptions from this query is that they tend to ask for "Java" when they mean "J2EE" or "Java EE" and it appears ".NET" is a great big catchall for all things Microsoft and perhaps not representative of the equivalent in Java/J2EE. You can make up your own mind and decide what the heck recuiters think when writing job descriptions by looking here ...

http://www.indeed.com/jobtrends?q=php%2C+ruby+on+rails%2C+java%2C+.net%2C+j2ee%2C+c%23



To me the reality of .NET versus Java/J2EE is developers have to know both rather than one or the other. Our recent Microsoft Office Interoperability documentation book which focuses on how Oracle Application Server components integrate with and interoperate with Microsoft, I think more closely represents most developers' reality, though clearly many organizations still like to strategically align with one community or the other.

Interested in Hibernate on Oracle Application Server? Check out some of these articles:

http://www.oracle.com/technology/tech/java/sash.html
http://www.oracle.com/technology/pub/articles/vohra_hibernate.html


Interested in JSF on Oracle Application Server? Check out some of these articles:

http://otn.oracle.com/jsf


Interested in EJB 3.0 and JPA on Oracle Application Server? Check out some of these articles:


http://otn.oracle.com/ejb3
http://otn.oracle.com/jpa

Interested in Spring on Oracle Application Server? Check out http://www.oracle.com/goto/spring - many of these articles and how-tos recently arrived also on http://www.springframework.org.

Java Process and Instance Data From OracleAS

In the Oracle Application Server it is standard practice to set up a cluster with multiple application server instances hosting multiple OC4J instances each run atop of multiple JVMs.

Frequently when executing a specific application instance (servlet/EJB/Web service), it can be useful to have the exact location you are running - which Application Server instance, which specific OC4J instance and sometimes even the exact JVM instance. Sometimes you need this for your application to make some application centric decision, but more often it is useful for debugging when working in large clusters.

This blog is inspired by Steve Button's work where he built a very cool utility for session tracking in a cluster which implicitly revealed this information - he needed it himself while building it to debug as well to show to the user.

So how do you determine this on Oracle Application Server? There are several system properties that will help you out, specifically:

• oracle.home - the physical directory in which your application server is installed
• oracle.oc4j.instancename - the name of your OC4J instance
• oracle.ons.instancename - your OracleAS instance name
• oracle.ons.indexid - a combination of your OC4J instance name, the group it belongs to and the actual JVM executing it (for example if there is > 1 JVM you have configured as per my previous post on this topic)

On my cluster - I have a lot of AS and OC4J instances running :-) ... but in the picture below you can see that for this sample, I have highlighted the pieces of interest. In particular, one of the Oracle Application Server instances is named is soa_javaee.MLEHMANN-LAP. In that instance I have several OC4J instances, one in particular called javaee_1 that is configured to run on top of 2 JVMs. That OC4J instance is grouped together with several others in a synchronized group called javaee_group. If you look to the bottom of the graphic below, you will see this:


To try out these properties, I deploy a servlet to that OC4J instance javaee_1 and within that servlet I have the following code:

out.println("

Oracle home name: " + System.getProperty("oracle.home"));
out.println("

OC4J Instance name: " + System.getProperty("oracle.oc4j.instancename"));
out.println("

AS Instance name: " + System.getProperty("oracle.ons.instancename"));
out.println("

Instance:Group:JVM PID: " + System.getProperty("oracle.ons.indexid"));

What it spits out the other side in my browser is:

Oracle home name: D:\oracle\product\soa_javaee
OC4J Instance name: javaee_1
AS Instance name: soa_javaee.MLEHMANN-LAP
Instance:Group:JVM PID: java_ee1.javaee_group.2

Pretty useful information ... try it out :-)