Choosing an OSGi distribution: Equinox, Felix, Gemini or other
Which OSGi distribution should you choose for your Java projects ? I've been asked this question several times, given that I wrote a book on the subject of Spring-DM .
In case you're also starting to use OSGI or Spring-DM in your Java projects, here are some things to consider when choosing an OSGi distribution.
Continue reading : "Choosing an OSGi distribution: Equinox, Felix, Gemini or other"
October 25, 2010 | Permalink | Track Back (0)
Java: The king is dead. Long live the king
It's always interesting to see articles on the demise and success of a platform, especially when they're published on the same date. And it appears the higher-profile a platform is, the more intense the dialogue is. In this particular case I'm referring to Java.
The problem though is that Java is a huge platform, so saying its 'dead' or 'its the greatest technology in the world' is likely to be skewed. What part of Java exactly ? Mobile devices running J2ME ? Server-side web applications using JSP's/Servlets ? Game development ? Desktop applications ?
I wont focus on the negative aspects, since you can easily search the web for these often fruitless discussions. I will focus on what I've personally experienced and read are very productive and successful Java projects.
Continue reading : "Java: The king is dead. Long live the king"
September 30, 2010 | Permalink | Track Back (0)
Sun's metamorphosis into Oracle : The fate of Java, hardware and people
When it was first announced that Oracle would buy Sun, as all mergers of this size, there was rampant speculation on just about every front: How many jobs will be cut ?, What will happen to Java ?, What will happen to Sun's hardware/processor lines ? , What will happen with....
Slowly but surely, the results are starting to materialize. Which include the departure and inclusion of heavyweight IT names, as well as the reassurance and cancellation of certain product lines.
Continue reading : "Sun's metamorphosis into Oracle : The fate of Java, hardware and people"
September 24, 2010 | Permalink | Track Back (0)
Java 7: Finally reducing the need to use 'finally'
Every language has its quirks, but one that has always irked me is Java's try/catch/finally block. Don't get me wrong, I perfectly understand the purpose of the try/catch syntax, defining a block with all the possible errors that can be raised by certain logic and handling each one in a separate manner. C# also uses a try/catch syntax, while Python relies on a try/except syntax. So what's so annoying about Java's finally ? That you often have to use it in situations that seem redundant.
You will often append 'finally' to a try/catch block when you have to execute instructions whether the logic in the try/catch block was executed successfully or unsuccessfully. If the logic in try suddenly crashes, it will immediately fall-back on a catch section, which can leave some 'to-do' tasks., so you rely on finally for specifying tasks that always need to be executed..
Among the most common 'to-do' tasks, I would venture to say 90%+ are clean-up tasks. This can range from closing a database connection to closing a file stream used in the context of the try/catch block. Since a sudden error can leave these resources 'open', you rely on finally to guarantee they get closed, ensuring that no memory-leaks or garbage collection issues arise on account of them being left 'open'.
But couldn't Java just close these resources for you automatically ? Until the advent of Java 7 and automatic resource management, it wasn't possible. Here is how it will work with automatic resource management(ARM).
Continue reading : "Java 7: Finally reducing the need to use 'finally'"
September 17, 2010 | Permalink | Track Back (0)
Java build tools: Why Ant will never go away and Maven will never prosper
I recently had a discussion on what Java build tool to use for a particular project. Its a small project in terms of the amount of code it will use -- a book project to be exact, with all its examples. But one of the co-authors suggested we use Maven. Even though I've learned to use Maven I shy away from it, but now that my co-author has hinted with A Survival Guide to Maven, OR, Why Maven's Still Cool , I thought I'd write this post on why Ant will never go away and why I believe Maven will never prosper.
Continue reading : "Java build tools: Why Ant will never go away and Maven will never prosper"
September 1, 2009 | Permalink | Track Back (0)
OSGi's service model, more than just versioning
In an earlier post I described OSGi versioning and Java's run-time and how the former is often discussed with the latter, since Java lacks run-time versioning. In this post I will describe another OSGi feature, one that although not as fresh a concept as Java versioning, is still central to OSGi: The OSGi service model.
Continue reading : "OSGi's service model, more than just versioning"
February 19, 2009 | Permalink | Track Back (0)
OSGi: Versioning and Java's run-time
When the topic of OSGi comes up it often comes hand-in-hand with the term versioning. In short: 'Java has no support for versioning and OSGi does, so OSGi fills this void'. But how does this versioning mechanism work and what implications does it have for a Java application? This post will attempt to summarize how OSGi, versioning and Java's run-time fit together.
Continue reading : "OSGi: Versioning and Java's run-time"
February 17, 2009 | Permalink | Track Back (0)
OSGi and server side Java : Implications and how does it actually work
OSGi is slowly but surely moving into Java server-side territory and a few other SOA product lines in the industry. Among the most noted, you will find a few of the earliest Java Application Servers now being tagged 'OSGi compliant' or 'OSGi based', in addition, popular Java frameworks like Spring have also blossomed OSGi integration sub-projects. But what are the actual implications behind OSGi ? And more importantly how can you work with it ? This entry covers an article I recently wrote on the subject which includes a hands-on OSGi example, as well as the potential implications OSGi will have on the overall Java and SOA ecosystem.
Continue reading : "OSGi and server side Java : Implications and how does it actually work"
January 7, 2008 | Permalink | Track Back (0)
Archives Java
Apple says : Hello Python and Ruby, and almost farewell Java
October 30, 2007 | Track Back (0)
OSGi takes on Server Side Java and SOA.
July 13, 2007 | Comments (1) | Track Back (0)
Java and .NET interoperability without web services : JMS, MSMQ, CORBA, JNI and DLL's
April 4, 2007 | Track Back (0)
Sun's Project Tango : Java Web Services technology united.
September 10, 2006 | Comments (1) | Track Back (0)
SDO revival and SCA.
June 9, 2006 | Track Back (0)
JSF Frameworks : Shale and Seam
May 22, 2006 | Track Back (0)
Web Services in EJB 3 and WCF very much alike.
April 4, 2006 | Track Back (0)
JSF : Another approach to J2EE web-tier development.
January 14, 2006 | Track Back (0)
SCA - Service Component Architecture, your SOA's working pieces.
November 30, 2005 | Track Back (2)
Groovy : A case for Java's Scripting Language.
November 15, 2005 | Track Back (0)
WSRP and Portlets.
October 30, 2005 | Track Back (0)
The JBI debate : To SOA or not to SOA.
July 12, 2005 | Track Back (0)
Java highlights from JavaOne: Open Source and Hardware.
June 28, 2005 | Track Back (0)
BEA unveils AquaLogic product line for SOA.
June 8, 2005 | Track Back (0)
EJB 3 : New Spec - Old Tricks
May 13, 2005 | Track Back (0)
J2EE vendors moving up the stack -- without Java ?
May 1, 2005 | Track Back (0)







