Java


Matt Asay wrote a well received post about dynamic scripting languages such as PHP, Perl and Python ‘crashing the enterprise party’. While the Indeed.com job trends chart that Matt used is somewhat misleading, the chart isn’t central to his point. I say somewhat misleading because the chart tracks percentage growth of jobs seeking “Java”, “PHP, “Perl”, “.NET” and “Python” skills. It’s not surprising to see languages with little enterprise penetration growing faster than languages, or platforms in the case of .NET, that are virtually de facto standards for non-legacy applications. The ‘absolute’ version of the Indeed.com job trend chart is more reflective of the market demand for Java, PHP, Perl, .NET and Python skills.

In any case, Matt’s concludes:

“No, Java and .Net aren’t going away anytime soon. But then, neither are the dynamic programming languages, which are increasingly blessed “enterprise ready.””

I completely agree. Forrester’s Jeffrey Hammond’s research supports the growing enterprise interest in dynamic scripting languages:

“It’s also no surprise to see that dynamic languages such as Ruby, Python, PHP, and JavaScript are proving most popular with developers in the 45-and-under cohort. Dynamic languages are useful when it comes to assembling components into composite Web applications, especially if runtime composition is important.

The implications? As the development staff at a shop turns over, the new generation will push to adopt these dynamic languages. IT managers must ensure that processes and application life-cycle management tools can handle the changes that these new languages bring to the development shop. “

Hammond’s research also found that developers are increasingly comfortable working on multiple programming languages. Hammond writes:

“Developers used to identify themselves by the languages that they used — “I’m a COBOL programmer,” “she’s a Java developer.” But that’s changing — less than 15% of the developers we surveyed spend all their time writing in a single language. “

I started to wonder if the increase in dynamic scripting language job postings is being driven by companies seeking enterprise developers with multiple programming language skills. For instance, if a job required Java skills and another job required Java, Python, MySQL, Ruby on Rails and PHP skills, Matt’s Indeed.com job trends query would find 100 percent of jobs seek Java skills while 50 percent of jobs seek PHP skills. Clearly, the first job has an emphasis on Java development, with Java coding likely making up the majority of the work week. The second job may also be a predominately Java job, but there may be the odd PHP coding task required. As such, claiming that the second job is a “PHP” job while the first job is a “Java” job is somewhat of a difficult conclusion. This can be remedied with Boolean search operators as I’ve done, as shown in the chart below.

The overwhelming majority of jobs requiring PHP skills do not require Java or .NET related skills. My hypothesis that the growth of PHP jobs was a byproduct of companies seeking a Java or .NET platform developer who also knew PHP appears to be unsupported by the Indeed.com data. Java developers tend to be compensated at higher levels than dynamic scripting language developers. Companies may not want to pay a Java developer to work some percentage of her day on PHP coding when a PHP developer could be hired for lower cost. Makes sense, but I would have expected more overlap between Java and PHP jobs or the .NET platform and PHP jobs. You learn something new every day!

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

While the future of JavaOne is anybody’s guess, it’s interesting to note that Microsoft and IBM are both delivering keynotes at JavaOne this year.  This is Microsoft’s first JavaOne keynote and IBM’s first in at least 2 years.

Microsoft’s Dan’l Lewin will be discussing .NET and Java interoperability.  It’s great to see .NET and Java interoperability get more industry attention.  For all the .NET vs. Java hype, at least one-third of customers (an old Gartner stat) have both .NET and Java.  In fact, I spoke to two customers in the last month who are interested in the WebSphere CEA feature pack and have a .NET front end speaking to a Java back end.  Good thing we designed for interopability from day one.

It seems there may be a cloud angle to the Sun & Microsoft announcement.  I’d hazard a guess that Sun and Microsoft will announce support for “Java Services” on Microsoft’s Azure Cloud, similar to the .NET Services currently supported.  It’s always seemed awkward to me that Azure would be a Windows/.NET centric (only) cloud.  Why would Microsoft choose not to address the one-third of customers that have .NET and Java in their shop?  I have to believe that Sheila Gulati, Steven Martin, Sam Ramji, Robert Duffner, Bill Hilf and others at Microsoft are thinking along these lines.

IBM’s Craig Hayman, will be discussing Extreme Transaction Processing (XTP) and Elasticity, two hot trends in the enterprise Java arena.  As core business applications built with Java face exponential user and transaction growth, enterprises can’t really rely on a “Fail whale” strategy.  Elasticity and XTP work hand in hand to address this growth with an eye on reducing costs across peaks and valleys.  Craig will also cover how IBM’s efforts in the open community, both through open standards, and open source, are driving developer productivity and innovtion.

I would have liked to attend JavaOne this year, but we’re taking wee Isaac to visit family in Ireland.  If he fares well on this 6 hr flight, the ~20hr trip to India is up next!  Clouds, Java, .NET and XTP will surely be waiting we get back.

I haven’t really followed SourceLabs for a little while now, and yet, strangely enough, they’ve been doing new and interesting things even without me watching ;-). SourceLabs “Self-Support Suite for Linux and Open Source Java” caught my eye, so I thought I’d learn more about it. I watched a demo that began with the slogan: “We’re IT people…we don’t call support”. Made me laugh out loud…

The useful thing about the Self-Support Suite is that it adds diagnostics to your applications. When developers have a support issue, the diagnostics results are used to search for the similar problem *and* the solution from within 16 million data points in the SourceLabs support repository. The repository is constantly updated with information from mailing lists, bug databases, code repositories, security bulletins, etc. There’s only one catch; what if there isn’t a solution available yet?

This is where OpenLogic comes in. (Remember that OpenLogic provides support for hundreds of OSS projects in one convenient support package).

While developers may not (like to) call support, it’s more than likely that their manager or their business would much rather that the support issue is dealt with ASAP. The combination of SourceLabs and OpenLogic would provide compelling value to developers, managers and businesses. The merger (or acquisition) would address the needs of developers wanting to solve problems themselves and managers wanting to ensure there is a safety net for the business when a solution isn’t easily found.

Seems like a win-win-win for OpenLogic, SourceLabs and customers.

I’m sitting here beside Sun’s A. Sundararajan before the JavaOne keynote starts. He is one of the core developers on Sun’s HDcookbook project. I didn’t know this, but all of our Blu-ray players have a J2ME JVM inside. So, if you want to create a Blu-ray disc, you’ll need to write some Java code. A. Sundararajan and team are tying to make this easier by offering libraries and tooling for developers. It’s all under the BSD license, so have at it.

Apparently Canada’s Neil Young is here at JavaOne to make an announcement about Blu-ray…

Captain Canada over and out.

Because I’ve been a hermit over the past few days, I’m only now reading about Sun’s open source event earlier this week. Sadly, I wasn’t invited (likely because I work at IBM and I’m a peon in the OSS landscape). :-)

Looks like there was more news about Project Indiana, Glassfish, and OpenOffice. I wonder if there’s a place to get the presentations that were used?

This statement caught my attention:

“Red Hat has created a project called Ice Tea to make OpenJDK run better in a Linux environment, Reinhold said.”

Just because two JDKs pass Sun’s test suite doesn’t mean there won’t be (unexpected) differences in the way they handle the same Java application. Sun’s TCK (Technology Compatibility Kit) attempts to minimize the impact of these differences, and generally does a good job, but differences will exist. That’s why most ISVs state which JDKs are supported. If your ISV says their Java product runs on all the leading JDKs, it could be that they’ve tested their app on the Sun, IBM and BEA JDKs. Or it could mean that the ISV has tested with one of these three (or an alternative) and is relying on Sun’s TCK tests to ensure there won’t be unexpected results on a different JDK. This isn’t such a bad strategy 99.99% of the time. But there must be a reason that some ISVs test on multiple JDKs ;-)

I wonder what % of ISVs will be enamored by the news that Red Hat is creating another JDK that could be added to the ISV’s test matrix. Being an OpenJDK variant helps if the ISV is already testing with the Sun JDK. But, a little different may be different enough. If Red Hat’s JDK doesn’t gain much traction (which is my guess, largely because of the ISV testing and support challenges), will Red Hat have spent their time tuning/improving the Sun JDK for RHEL?

Anywho, here’s a good description of Ice Tea from a Red Hatter.

Having spent the better part of my career working with products that are based on JEE, I sometimes have to remind myself that .NET is still quite prevalent. You’ll find that there are customers who are “JEE shops” or “.NET shops”. But a fairly large portion of customers have both JEE & .NET in their IT environments. I saw a Gartner estimate of JEE only/.NET only/ JEE & .NET/Other architectures representing 25%/25%/35%/15% of all customers. Take that “data” with a grain of salt as it’s old and based on my fuzzy memory. The larger point is that a significant portion of enterprises have both .NET & JEE.

We could argue about the pros/cons of each architecture, but customers seem to have voted with their wallets and use each as appropriate to address business needs. This statement could equally be applied to the OSS & Traditional software discussion.

I had the opportunity to speak with Jenna Dobkin from Mainsoft last week. (Mainsoft is an IBM business partner). Mainsoft provides .NET to JEE interoperability by allowing .NET apps to be cross compiled to run natively on a JEE runtime. I was intrigued by the technical feat behind Mainsoft’s offering. It allows customers with .NET skills and assets to continue benefiting from their previous investments while being able to deploy to JEE platforms. Why JEE? Well, it could be because customers want the performance, reliability, availability, etc. benefits of JEE. Maybe they want to shift towards open standards-based applications. Maybe their end customers are “JEE only” shops. Maybe dropping the “2” from J2EE did the trick!

Jenna put me in contact with two Mainsoft customers to understand why they didn’t *just* deploy to .NET or *just* write in JEE. Note the emphasis on my implied simplicity of the word “just”.

I spoke with Bart Sijnave, the CIO at UZ Gent, a university hospital in Belgium. I also spoke with Atul Mistry, VP of Technology at Urix, an ISV in the healthcare industry.

Both Bart & Atul indicated that their organizations had .NET skills and re-training their developers (teams of less than 20 in both cases) for JEE was not a viable business option. Bart suggested:

“If I had a larger team, I would add JEE-specific development skills. But I could not meet my customer’s time-sensitive demands if portions of my team were out getting re-trained”.

UZ Gent uses RHEL and other OSS products and looks for opportunities to expand OSS use as appropriate.

Atul said:

“Business is the key decision criteria for us. If you have to reinvent the wheel because of a religious technical belief then you are not doing the right thing for your business.”

Urix has customers whose IT environments are largely Unix based. Faced with not addressing these customers or adding new staff to port the application and continue development on Unix, Urix made the business decision to use Mainsoft. Urix also uses OSS technology such as log4net and other OSS technologies aimed at Microsoft developers.

Both organizations are believers and users of open source products. But, for these two companies, business results trump beliefs. I suspect this is the case for the majority of customers. This is why I believe that OSS will never truly “take over” the software world, nor will OSS fade away. Pragmatic customers wouldn’t allow either to occur.

Customers have to be pragmatic because their business depends on it.

During the opening day SpringOne keynote yesterday Interface21 explained how they plan on using the funding they recently secured. Later in the day, I spent a few minutes with Neelan Choksi, COO at Interface21.

Neelan explained that for Interface21, the use of an open source license (Apache License 2.0), an open development model and a free product with paid support business model is about one thing, developing software. Yes, Spring is open source software, but that was a pragmatic choice. A choice born out of the market landscape at the time, not from an ideological love of all things open source.

Keeping this in mind, it shouldn’t surprise you that Interface21 announced they’d use their funding to, amongst other things:

1] Rod & business functions are setting up shop in Silicon Valley to be closer to partners, investors and advisors
2] Setting up small, but growing, product development centers in the UK (Southampton), US (Melbourne, Florida) & Canada (Vancouver) because they feel co-located employees speed product development
3] Hiring seasoned Sales reps to go after larger enterprise deals
4] Hiring seasoned Marketing professionals to market to VPs and CXOs
5] Continuing collaboration with Microsoft to bring Spring to .NET developers

Clearly, Interface21 is going to do a lot more with the funding. I wanted to highlight these 5 because they are counter to “conventional wisdom” we hear from OSS visionaries.

Moving key staff to Silicon Valley, co-locating development teams, hiring professional sales teams (i.e. the expensive professionals driving Porsches), spending significantly on marketing and working with Microsoft are steps you’d expect from a software vendor. Good to see Interface21 acting like a software vendor and leaving others to play the part of an open source software vendor.

One other thing that Neelan mentioned that gave me the warm and fuzzies. He spoke about the funding process and how many VCs came to Interface21 explaining that using open source meant they wouldn’t have to spend much on sales or marketing. These VCs were, shall we say, excluded from the shortlist, because as Neelan and Interface21 understood, that’s a piece of conventional OSS wisdom that doesn’t hold when you’re trying to scale the business.

Interface21 is pragmatic about building a viable software business. Good on them.

Next Page »