I mentioned that along with a number of my team, I have the pleasure of attending JAX Mainz in just over a week's time. I'll be giving a keynote on some of the challenges facing Java and the JVM in the future, particularly in the area of cloud and mobile. I continue to believe that these new frontiers can and should benefit from the experiences the Java communities have learned over the years. Of course there are technical challenges that cloud and mobile present which we haven't always had to consider in the past, such as scalability. But sometimes I think that the challenges aren't always technical: the "not invented here" syndrome is something I've encountered throughout my three decades of software development, so it's not just the domain of these new technological waves. But it is there and hopefully we can work together to break down these barriers. I've blogged before about how I think JBoss can help a wider range of communities than we are traditionally associated with. However, a while ago I also had to write an article that made it clear that we are still very much in the Java world. This came about because there were concerns that we may be spending more time on "sexier" languages than Java or the JVM. But recently I've started to hear another concern that can probably be summarised as: JBoss is firmly in the Java arena and has very little to offer languages that don't reside on the JVM, whether they have their roots in the 20th Century, such as C or C++, or the 21st Century, such as Go.

Unfortunately yet again the truth is somewhat different if you stop to think about things. Anyone who has been working in the area of SOA will understand what I'm about to discuss and if you've ever used CORBA then you're probably already at the conclusion! Like it or not, CORBA and IDL were very successful in illustrating how you can have a language agnostic approach to building distributed systems. Simply define your service or object in IDL and then have a compiler produce the associated client and server stubs. From these you can construct your application and it really doesn't need to know how the constituent pieces are implemented. And CORBA has been around long enough to support many different languages, even COBOL! Despite no longer being as popular or widely used as it once was, it and the OMG are still around.

Now of course you may not want to use CORBA, but the principles that it illustrated (language agnostic invocations between objects or services) can be provided in a number of other ways, several of which are also standards based. These include REST (whether over HTTP or some other protocol if you want to improve performance, such as SPDY), Web Services (yes, this is another one that will split the community into supporters and detractors, but it is very widely available and deployed), or messaging implementations such as those supporting AMQP (OK not quite a standard yet, but it's heading in the right direction and will be there soon).

So you can construct applications, components, services etc. out of other components or services that are not necessarily implemented in the same language that you are using currently. In fact they may not be implemented in the same language as each other, if you are using several services at once. And building applications from distributed invocations (building distributed systems) is a lot less intensive than building core components from scratch (yet again). Believe me ... I've been there, done that and got several t-shirts to prove it! You really don't want to be implementing transactions, security, persistence etc. from scratch when there are perfectly good implementations out there that can be "wrapped" in your language of choice.

Of course there are a different set of issues to be considered when building distributed systems. These include performance and fault tolerance, but our industry (and academia) has many decades of experience in tackling these. So they should not be used as an excuse for ignoring middleware stacks, or individual components, that exist already. And yes, although I started out talking about JBoss, this really is an argument that can and should be applied much wider. I'm not suggesting we don't consider implementations from scratch, but that we don't have that as the initial reaction to every problem that comes along! So whether you're building in COBOL, C++, Java, Ruby, Lisp etc. if you've got a need for core services that we take for granted in enterprise middleware stacks such as JBoss, don't rule out either using the entire stack or cherry picking from it just because it's implemented in Java: you don't have to know Java or even use a JVM to benefit from the years of experience and maturity we offer.