Thursday, November 30, 2006

C++ Inventor on Modern Software

For those of you who regularly peruse sites like dzone you've probably already come across this article, but I thought I'd highlight it anyway.

Over at Technology Review there is an interview with Bjarne Stroustrup, the inventor of C++. Makes for some very interesting reading, he talks amongst other things, about software quality and why it is generally so poor. Well worth the read. It's a well balanced view and I'm sure for us developers there will be ring of truth about it.

In one section he starts by saying how there is some very good software out there, citing examples like the Mars Rover, Google and the Human Genome Project and points out that 15 years most people, even most experts would have pronounced these examples impossible. He also says that modern civilization depends on software so if software really was that bad, we'd probably all be dead by now.

He then turns his attention to the "average" piece of code and has the following to say...

I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.
The rest of the article talks about a lot of other interesting things surrounding C++ and programming and how there are two kinds of programming languages in the world, ones which every complains about, and ones which nobody uses.

Monday, November 27, 2006

Google - the new internet

In my day job as a programmer there are a number of sites a frequent fairly often, namely amongst others, the hibernate site and the xdoclet site. What is interesting is that I have found myself using the handy google search box in firefox to find these sites rather than a. use the bookmark or b. type a url into the address bar. It is a pity therefore that the google search box does not allow for a "I feel lucky" invocation as more often than not that is just the site I am looking for.

It's quite interesting to note as if I am only using google to access the internet and always using the I feel lucky selection then whose network am I really browsing. It is as if I'm operating on google's "internal internet!".

And I would be quite happy to do this. Typing in a search term into a google search is far more intuitive than typing or what ever the appropriate url is, I don't know as I just type "hibernate" into the google box and select search.

powered by performancing firefox

Wednesday, November 15, 2006

Welcome to this new funky blogging tool...

Wow, I am lank impressed with this new blogging tool. I do not even have to go near the site in order to publish something, how awesome is that!

powered by performancing firefox

Tuesday, October 31, 2006

Why I hate frameworks...

If you haven't seen this link, then go and take a look. It's hilarious, because it's so true to life.

why I Hate Frameworks

It's brilliant.

And having been exposed to spring in a big way recently, I can see there is always a danger of that occurring. I guess the rule of thumb is to a. be pragmatic, and b. not be a servant of the framework. Keep the end in mind.

Tuesday, September 26, 2006

How to do web services?

The project that I am currently on has been my first real exposure to enterprise grade, mission critical web services and I must say it's a real challenge.

What makes it even more challenging is that the project has a dotNet front end and a java back end, so we have to make the web service inter operable.

Let me start by just pointing out that we are using IBM's Rational Application Developer Platform version 6 to do the development, this does have a significant impact on your modus operandi, not only because of IBM's how can I say, blindness but also because of the current nature of web services development

When we stated out we were going the route everyone starts with, generating the WSDL and the web service plumbing from a java class, be that a session bean of a POJO. This as you may or may not know is not the best practice approach, and that shows when using RAD. In fact, IBM might as well remove the ability to generate wsdl's from java code RAD does it so badly. I know why it is not recommended.

Because of the fact that RAD is so poor at doing this and because none of the team knew how to hand code wsdl's, a notoriously complex job, we went a generic route where we have one web service which receives two strings, one for the details of the method to be called and another for the arguments. The translation between xml and objects is therefore our responsibility, and not dealt with by the application server and generated code.

We selected castor to handle this for us.

I then went on a mission to educate myself about wsdl's, and the surefire way to do this is to buy a book, which I did, Web Services Essentials (O'Reilly XML). That sure helped break the back. I was very chuffed when I successfully hand coded my first wsdl file that not only successfully validated with RAD but RAD also did an efficient job of generating java skeleton code from it. First I started with a hello world wsdl and then built one where an xsd file was referenced to provide the communication protocol.

I must say, it was not as difficult as I thought it might be - I also realised that most of that complexity is necessary. This is often the case, things are perceived to be complex because they are not understood.

One thing is for sure however, and that is that RAD's wsdl editor is a load of crap!

So to continue on my journey, generating java skeleton code from a wsdl is a painless process in RAD, whether you generate to a session bean or to a pojo.

The problem is, and this what I'd like to focus on, is that the web services runtime for Websphere (other web service run times as well), generate java source code for the communication objects from the schema. Now it is absolutely necessary that you use schema's (xsd's) to define the protocol in order that the client and server can understand what each other is saying, but the problem is this generated code.

Typically, in the schema you're going to have objects defined by the schema which are already defined in your code and if you've already built these objects, then you're going to have two versions. One generated and one hand coded, and you're probably not going to like the one that is generated.

Before continuing I'd just like to look at why it is done this way because there are technologies which allow you to take already existing java classes and map them to a schema (castor, jibx, et al). I think the builders of web service runtimes have taken the route to generate classes from a schema, the pojo as well as some kind of helper that knows how to marshal and unmarshal the pojo, because that way they can guarantee that the marshaled xml conforms to the schema. If they leave it in the hands of the developer to provide the mapping between the already built pojo and the schema, they cannot guarantee that this mapping is correct. I wonder if annotations and generics (which we cannot use because IBM is slow), could annotate already existent classes and save us this trouble.

Typically, generated code is not preferred. Developers like the code to be the way they like it.

You have another problem however, how do you copy between the dto objects and your value objects? Manually - are you kidding... If you have to do it manually then I'd rather re-use my value objects. If on the other hand you can in fact use reflection, fast becoming pervasive in computing environments, then it will in fact be a pleasure.

Watch this space for more lessons learned on the enterprise project.

Thursday, September 07, 2006

.net first impressions...

I have always been a java developer and since joining my current company, which does java and .net development, I have looked forward to the day when I would get exposure to how the .net platform works...

The project I am currently on has both .net and java elements and I have thus been able to dip tentatively into the world of dotNet.

The first thing I've discovered is that my learning the dotNet environment requires my learning a whole new IDE, and this, given the complexities and capabilities of modern IDE is a "double difficulty". Not only do I have to learn a new IDE but I also have to learn a new language. It is debatable which is more difficult.

If you consider that now only do I know java well but I also know eclipse (a java IDE) well and it would take me a long time to learn another java IDE, and it's not something I would find easy. Thus discovering the dotNet environment becomes doubly as difficult because I have to learn an IDE as well.

Now I must be careful of not making the mistake that I throw the book at the C# guys for doing, and that is condemning the platform because of the IDE. I can understand their thinking because for them there is only one IDE, thus the platform is the IDE.

Fortunately, in the java world, this connection is not so strong because there are a number of different java IDE's and thus you can choose the one that best suits your needs.

I think the point I'm trying to make is that learning a new platform is not simply learning the language and the intricacies of the platform, but also learning the IDE that goes with it. This is probably a bigger task than the language itself.

But then you may ask, so what are your first impressions...

I am not ready to comment on c# as a language as I do not know enough about it, but I can make some comments on Visual Studio... Do not see this as a comparison between c# and java, but merely as a comparison of two IDE's, regardless of what language they are for.

I think the first thing that must be said is that VS is unbelievably responsive! It is like waiting right outside the door to give you what you need. It is like the waiter who does not let your glass even get half full before he is on hand to fill it up. The java IDE's in general (possibly because of the non native nature of the gui), are more like the waiter who comes round every 5 minutes or so to make sure your glasses is full. Still gets the job done but just not so quick.

I must point out however, that it is probably not much more than a "nice to have". A lot of the facilities I've come to depend on in Eclipse just aren't there in VS. When I say facilities, I mean "micro facilities". It is also very difficult to assess an IDE objectively, first impressions are always clouded by the "I can do this in eclipse, why can't I do this in VS?".

I'll continue to report on my progress through the .net environment, as and when progress occurs.

Monday, July 31, 2006


Recently I have been assigned to a project at a company about 50 minutes from where I live. I therefore find myself spending a lot of time in traffic. It is less than ideal.

I can remember a friend telling me how he used to use his traveling time to think and make notes etc, possibly on some kind of voice recorder or something. He was making the most of the time spent commuting - it was even more than the time I currently spend commuting.

I felt that I needed to leverage the time spent commuting. In this regard I discovered podcasts. Now I would concede that in more "advanced" societies, i.e. the First World, there is more familiarity with these kinds of concepts, and better access so I am a little behind the times. Nevertheless they have enriched my commuting experience substantially.

I can now spend the time that I otherwise wasted keeping abreast of the latest developments in the tech world - the podcasts are all tech podcasts.

And for those people that think podcasts are much the same as reading the content - they are not, they are far more entertaining and interesting as you can have dialogue between for instance, a protagonist and an antagonist. Besides, I can't read and drive simultaneously.

The regular podcast I listen to:
  • zdnet's podcasts and specifically the "Dan and David Show". - this is the one I listen to regularly. It is a very entertaining and informative podcast for keeping up with the latest trends in the tech world.
I tried the "Mike Tech Show" but it was far too simple.

If you have any podcasts which I should try, then pass them on.

Friday, June 02, 2006

Google Chat - how do they do that?

Okay, so we know how to submit from the client asynchronously...

The question is, how does google chat do it? For those people that haven't used google chat, it is a web based chat client which behaves just like a normal one.

In other words, if I'm in a chat session with someone I get messages like "Bob is typing", and when Bob finishes typing, then bobs messages comes through. It appears as if the server is initiating communication with the browser! How do they do that?

The exercise started off by wanting to look at how AJAX apps built with google web toolkit submit data to the server - for this I installed a very funky plugin called "firebug". I was looking for something that would enable me to view the xml http requests submitted by the browser and this is exactly what firebug offers, along with a whole bunch of other stuff.

I used firebug on one of my simple gwt apps, and it showed me what I was looking for, then I thought I'd try it on google mail. It wasn't long before I realised how google's chat works.

Very simple to be honest. Nothing profound at all! When you initiate a chat with someone and click enter, it sends that chat message, but also submits another one. This one does not return immediately, but only returns when the user you're chatting with writes something! If it times out, as far as I know, timeout is 90 seconds, then it will receive a "nothing happened" message and then submit another "if you have anything to say put in this bucket" message. In fact, multiple buckets can be submitted in order that there is always one available.

It shouldn't surprise you that this mechanism has also been given a name and it is called "Comet".

Wednesday, May 31, 2006

Google Web Toolkit - some experience now...

It was with relish that I embarked on putting the google web toolkit through it's paces. In fact, for the first time in long time, I coded for fun on the weekend. The recent addition of a laptop helped in this regard however...

For a long time I have wanted to build a simple database app to help out a local church. It's a simple app to manage a list of people, their particulars and other properties. Now I thought that would be an ideal test bed for the new google web toolkit - how cool would it be to make it a AJAX rich client app that runs in a browser. A familiar "link" would be all that is required. Because it will run in an intranet environment speed was not a consideration.

All in all, I was able to reach a fairly advanced stage, quite quickly. The API is very simple and easy to use. The "hosted" mode helps a lot. There were a couple of anomalies in the compilation of the javascript - you can't go wild with anonymous inner classes, the parser doesn't handle those very well, and there seems to be some conditions on your package names.

All in all, however, for an application of this nature, the google web toolkit is ideal.

I will have to do some work on the back end to get the data to persist, probably going to use flat files and an xml based serialization mechanism. It's very easy however to use stubs for those back end calls - funny how they're termed back end calls, whereas in actual fact they're simple request to an http server. With AJAX and DHTML the client is no longer dumb!

I had something else that I wanted to throw google web toolkit at (I call it "goowit" for short)...

Recently I built a Sudoku puzzle solver in java - complete with funky swing user interface and all - you enter the numbers, click go and it solves it. I was very keen to see if this would port to java script via gwt so that it can be deployed easily on the net. It took me a while to remove all the non gwt supported stuff - there were a lot of dependencies on java API classes not supported by gwt. I thought at one stage that it in fact would not work. In the end, it did, and I was very impressed.

So it was with great excitement that I finally got rid of all the "cannot import" messages on the hosted mode console - be aware that if an import fails it means that that the class has not been successfully translated, probably because it contains unsupported content. Once this was done, I entered my numbers and clicked go. In an instant it solved the puzzle.

Now for the final test, compile to javascript and see how it runs on the browser. This was where my heart sank, it was unacceptably slow. In fact, it probably would have taken about a day to solve one puzzle! The browser's "A script is taking too long" came up even before the first cell was picked!

Something which ran fine in hosted mode (java compiled mode) was far too slow in javascript mode. Now I'm not 100% sure exactly why - is it because the generated code is inefficient or just because job is too big for an interpreted language. I can't say. I think the rule of thumb here and it sounds obvious is to avoid doing heavy duty, complicated and long running processing with javascript. Not only because it may be slow but also because javascript is a single threaded environment and you need that one thread for keeping the gui snappy. Whilst a javascript process is running, the browser is totally non-responsive.

More exciting discoveries await...

Monday, May 29, 2006

Google Web Toolkit… a first look

When I was first exposed to the AJAX technology and how it works at the Sun Tech Days, I thought to myself, why then can't you code in java and get a tool which allows you to "press button for thick client", or "press button for thin client". It would have to be some kind of a cut down version of java because you wouldn't be able to do everything on a thin client than you can do on a thick client.

In a nutshell, this is what Google has done with their google toolkit. It is, like a friend first said to me, "a way to write AJAX applications with standard java code".

They have solved a lot of the problems and what they've come up with is something far more amazing than I was thinking at the Sun Tech Days. especially since, having seen google's solution, the number of issues that I was just plain not aware of are vast.

Let me mention however, that they have not solved the "deploy to thick client" - though in a sense their "hosted" mode is exactly that. I think because that need is in fact not required in any case. There are already API's available for building thick client gui's and besides, practically speaking thick and thin clients are so different that you would not be able to seemlessly deploy to whichever you choose.

Google's Web Toolkit - Summary of usage…

  • They have built their own set of gui controls - the functionality of which can be realised in html. If you start using them, and you are familiar with html you will soon see this. They are "wrappers" onto the features of the html controls. They also have some of the familiar layout managers - DockLayout (BorderLayout), FlowLayout, TableLayout and others.
  • They "translate" java code into javascript code. This, to be honest, is probably the biggest achievement of the google web toolkit. It is not therefore an AJAX toolkit as such. It is far more than an AJAX toolkit. This feature by itself is amazing. I have a sudoku puzzle solver that I built with a swing gui. I am very keen to see if it will translate into javascript so I can run it on the client (no AJAX). There are some limitations to what can be done, since java is not javascript. They also have a little bit more work to do on the parsing side - if you find that your code is not translating properly then you need to adjust the source code a little (it parses the java source code). The prospect of porting my sudoku solver to javascript by hand is not something I would dream of doing, this way I can see it in javascript, painlessly.
  • Handle AJAX calls with standard RPC infrastructure but with additions to make it asynchronous. For someone who's done RPC in any context, a lot of the concepts involved will be familiar.
    1. Build the remote interface, build the remote implementation of the interface
    2. Build the Asynchronous remote interface - contains every method in the synchronous interface but with call back reference added to each call.
    3. The process of calling is…
      1. Instantiate the remote interface (on the client).
      2. Specify the location of the "server" - in this case it is a servlet which you call.
      3. Make the call - when making the call provide an implementation of the AsyncCallBack interface. AJAX familiar people will recognise this concept.

It didn't take me long to write a simple web application in google web toolkit which takes two numbers as input and multiplies them or adds them according to the button that is pushed. When I get a site I can place this kind of content on (zip files) I will put it there so that people can acquire it. For now, if you're interested, email me and I'll pass it on.

I'm using eclipse and created two run configurations for GWT compile and GWT run. When they mean compile however, what is interesting is that they're converting the java code into javascript code. Going from one language to another! Believe me, making sense of the compiled stuff is impossible - they've obfuscated it quite a lot and rightly so.

The payload can be fairly big - a fairly simple app I'm busy with comes to 82K. It might sound like a lot, but when you consider that there is absolutely no library code on the platform on which it is running it puts it into perspective. There is no big JVM required, the client only needs a browser.

All in all, it is an amazing tool. I'm not sure if it is ready to write business applications on - but I do think that day will come.

Tuesday, May 23, 2006

Google and AJAX - Wow!

A friend pointed out to me that google has recently released a toolkit for ajax, and how you can simply code in java and the toolkit will do the work of web enabling it. That looks absolutely amazing! I can't wait to try it out.

Thanks Trevor.

Build Ajax apps in the java language

Tuesday, May 09, 2006

Eclipse and Netbeans... which is it going to be?

Having attended the Sun tech days last week I was exposed for the first time to netbeans. Now it is my bad that I haven't investigated the merits of this very impressive IDE before, for from what I saw there, it is very impressive.

In fact, I would say that it is so good, that it is insane to give it away for free. Some of the industrial strength you-typically-only-get-them-if-you-pay-for-them features that it has are an awesome profiler as well as a collaboration suite that is just amazing. That suite along with some VOIP installation and you never have to get up and go to the other developers PC! In fact, you can probably do remote pair programming.

But what are the differences between Eclipse and Netbeans and why so much bad love between the two camps.

I think the initial bad love started when IBM decided to eschew swing and build their own gui API. Swing was slow and just not "nice". IBM's perspective was that having a GUI look and feel that resembled the OS's native gui API was preferable, and I can see there point of view. Swing, with all it's progress that has most definitely made, does not look as "nice" as the native gui API's (windows and GTK).

So I set about giving netbeans run with gusto. It wasn't long however, before my initial enthusiasm was repressed. Having been used to eclipse's rich set of refactoring and code productivity tools I frequently found myself frustrated that a samilar level of functionality is not available in nebeans. For instance, Netbeans does not have the following quick fixes: "create class" and "create interface".

Another one of Sun's gripes on Eclipse is that they use a non standard compiler. Sun wants them to use "javac" which they don't. I now understand why. The java builder (eclipse speak) is a much more powerful tool as it is far more "on the fly" than the java one. This is because it holds dependency graphs so that whenever a change is made all the files which depend on that change are also recompiled. In netbeans the appearance of an error is not immediate. The javac uses very basic "is the source file newer than the class file" to ascertain the need for a recompile.

I could continue... the debugger, is also not half as fully functional as the netbeans debugger.

In conclusion - I would agree that netbeans is a worthy competitor, the profiler, gui builder and collaborative tools are world class. However, developers spend far more time actually doing the work of editing and compiling, and this is where netbeans runs a distant second to eclipse.

Monday, May 08, 2006

Sun Tech Days...

I had the privilege, last week, of attending the Sun Tech Days. It was the first time tech days were held in South Africa, and it was worth the wait. It was two days jam packed with great ideas, great collaboration, lots of learning, lots of sharing, lots of excitement, lots of great food (The food was particularly good) and lots of free stuff (managed to score 2 t-shirts, a bouncy ball, a java mascot as well as a sun tog bag and id tag in addition to the netbeans book I won for answering a question!).

Over the next few days I shall be blogging on some of the details on the conference. For now I'll provide short synopsis.

The first day opened with a keynote from James Gosling. I must admit, it was great to see the so called "Father of Java" in the flesh! Nice to know these people are actually flesh and blood like you and me. His opening key note was not amazing but did provide a number of pointers as to Sun's thinking on java.

The day continued with tech sessions on various technologies and infrastructures, some of the key technologies touted at the convention were AJAX, BPEL (business process execution language), Netbeans - a world class IDE and EJB3.

Sun has a lot of experience running these days and I must admit, it showed. The days were well organised and ran smoothly, the speakers were interesting and for the most part excited about what they were talking about. There were exceptions to this, though these speakers were without exception, non sun people.

The sessions were generally, very tech oriented - one techie talking to another techie - (no marketing blurb) and though they were at times a little basic, necessarily so, they had enough content to keep the familiar parties, such as myself, happy. I'm sure if I was totally unfamiliar with the technology I would have found the basics to be very interesting.

Johannesburg is an amazing place - Sandton must have the largest concentration of head offices anywhere in the country.

All in all, the conference was a success. I'm very glad that I was able to go, thanks to my company for sponsoring the trip. Though the value they gained out of it was far more than the money they put in.

Monday, March 20, 2006

Too many classes?

This is a post which was originally posted last year, under my other blog thoughts for life. I'm reposting it here because this is where it actually belongs.

I can remember, when I was in under grad, my brother said to me that when you're stuck on a programming problem then just add another class (the word class in this article is used to refer to interfaces and abstract classes as well as concrete classes).

At the time I don't think he or I understood how profound that statement is. How often does one come to code and found just two classes that do too many things, and then scratch ones head trying to figure out what's going on.

That statement is borne out of the notion that having lots of classes is a good thing.

Let's take an example from real life...

Analogy from the Real World
Imagine your motor car's engine was made up of 5 parts. When the starter motor breaks you have to remove the water pump as well because they're both from the same part. So you introduce potential for problems. Maybe the mechanic does not re-install the water pump properly, and so a problem that was just the starter motor now takes longer, with more risk because you cannot just remove the starter motor.

Transferring the analogy into the software design arena and you soon realise that the problems are far worse. A class which does many things which requires one change, there is an even larger risk factor than the engine analogy, because of the potential complexity software component.

To give you an example, a certain component of an application was particularly inefficient and for want of a better word, was just plain bad. I was tasked with upgrading (rewriting) it. When I was finished, the number of classes was about 4 - 5 times higher then in the previous version.

Here are some advantages of having many classes...
  1. Isolation of Bugs: In a system with many small classes, you have many relatively independent sub-systems all working together. If there is a problem, or a bug, chances are the bug will be isolated to one class, and only that class will have to change.
  2. Flexible to Change: I can remember times when I've had to make changes to an already built system and I spend a good part of the time figuring out how the current system works because the current system is comprised of very few classes. If the system were comprised of many small classes, then I would only have to understand many simple, small pieces of code. I may even find that the piece of functionality where the change applies is wrapped in one class already, and that class may even be named appropriately.
  3. Ease of Comprehension: Having many classes means you need less documentation. If you have one method which is rather large and you break it down into maybe two/three methods, and you name the methods appropriately then the method names describe what they do and the play the role that code comments would play in the larger method. The same is true when you break a system down into many classes.
  4. Potential for Good Design. I have found that when a system consists of many classes, chances are, the design is good. The number of classes would however, have to be relevant to the complexity involved, and this relationship is often an exponential one. As the complexity increases, so the number of classes increases even more. It is only by experience that one gets a feel for how many classes are appropriate to perform a particular job, but by and large, if the complexity is high and the number of classes is low, then the design is poor. If the number of classes is high this does not necessarily mean the design is good, but it is one of the indications.
I've heard rumours that in the past people were reluctant to have many classes with many methods because of the overheads of method calls and class intanstiation. The rationale for this consideration has been removed by efficiencies in modern compilers, virtual machines and the speed of hardware. Yes, you do incur an overhead when calling a method and instantiating a class, but, in general practice, I have found this to be negligible. Time and time again, design well, and then optimise rings true.

Real World Example
Why does this work? Well, it won't work if you just divide your large class into smaller classes in a naive way. If you were to divide a class into smaller pieces but still achieve the same degree of coupling between the classes as was previously the case, then you haven't achieved much. It is far more valuable if when dividing the class into smaller ones, the coupling level between the created classes is fairly low. In other words, the various classes do have a semblance of meaning outside of their context.

Take for example the problem that says
  1. Read in a file
  2. Count the number of words in the file
A naive approach would put all the functionality into one class which will read the file in and then count the words by counting the number of spaces. This would require one class.

A far more funky approach would be to separate the reading of the file from the counting, and if this is done with a low degree of coupling (via an interface) then changing the source location from a file to a string would be a simple process. If the counting is also done in its own class, then you could also change that algorithm to count say the letter 'a' without affecting the way it sources the file.

The classes that would be requried would be
  • Interface to communicate with the data source
  • Interface/abstract class to communiate with the counter
  • Concrete implementation of the file sourcer to retrieve it from a file
  • Concrete implementation of the counter to count spaces/white space
  • Controller to hook the two up
We've gone from 1 class to 5 classes in a very short space of time.

So when you code, do not be afraid to make many classes.

And when you're stuck, just add another class.

Friday, March 10, 2006

Get Perpendicular!

This is most hilarious...

Slashdot reports that "Hitachi has recently announced perpendicular recording with their harddrives".

That is good news because it means hard drives can get even smaller.

That is not the funny bit however, they've also developed a "music video" to go with it....

Absolutely hilarious!

For more information on perpendicular recording see the wikipedia article on it.

Tuesday, March 07, 2006

EJB JDO, what's going on

I've read with interest the discussion on the go between the JDO camp and EJB camp.

If you're not familiar with it, I'll give you a brief background.

EJB, more specifically "entity beans" is a persistence framework. JDO (java data objects) is also a persistence framework. The Entity beans framework is part of the broader EJB spec, currently in version 3.0. JDO is a "stand alone" specification in a similar vein to EJB in that Sun publishes the specification and a vendor then implements that specification and sells it on the market. JDO can be used in a desktop app, a web app or in an application server. Entity beans requires an application server to work and comes with significant overhead because of this.

I have used JDO extensively and have recently started looking at EJB in its version 2 guise. To be honest, the learning curve for Entity Beans is huge! It would take a developer twice if not three times as long to be useful under Entity beans than under JDO. I know because I was new to JDO at one stage and can remember how long it took me to learn. The developer would need to learn a lot of not specificaly persistence related stuff like session beans and local/remote interfaces.

There have been a number of discussions on the pros and cons of JDO against EJB. What makes the discussion even more interesting is that the latest EJB 3.0 spec, from what I've read, is unashamedly Hibernate! There are a number of conspiracy theories floating around as to why the EJB expert group went that way. The plot thickens when you consider that the JDO 2.0 specification is still in the process of being ratified - it has been rejected once already.

One of the loudest shouts in the community has been "We don't want two persistence frameworks!". My response to that is "why not?". It gives the user choice, it increases quality via increasing competition, it promotes flexibility. I say bring on alternatives.

This is the rationale behind the push on EJB 3.0. It seems that somehow this specification has won the day and that JDO has been abandoned. The primary reason for this I think is that because of the fact that Entity beans require an application server to work, the large vendors, Oracle, BEA, IBM, JBoss (who own hibernate btw), have supported the EJB specification because that way they protect their market.

To utilise JDO you do not need a heavyweight, complex and expensive application server.

The other apparent reason for the support of hibernate via EJB 3.0 entity beans is that hibernate uses standard sql as its query language. This not only locks the user into the underlying database but apparently affords the developer a seamless cross-over. I do not see how this can be seamless when the developer has to learn about all the overhead that comes with running on an application server.

I had to learn the JDO QL (JDO Query Language), and the syntax is a lot cleaner than SQL. JDOQL is far closer to object space than SQL is. It is just a more obvious and better fit when it comes to the object space. The key here is that it is far easier for an OO programmer to learn JDOQL than it is for an OO programmer to learn SQL. Which is why I do not buy the "they'll have to learn a new query language" rhetoric.

Furthermore, there is no reason why you can't use JDO with an application server. Again, surprise surprise, you have choice.

Reading various articles on the subject might indicate that JDO is dead, well, I was pleasantly surprised to note that the final round of voting on the JDO 2 spec is imminent. See jcp 243.
I'm holding thumbs for its adoption.

It probably won't be ratified however; based on the voting up till now a betting man would not put money on it.

Ultimately, I think that Apache opinion is correct and the most democratic and "broad based". They have always maintained "Let The Market Decide!". The specification is good enough, the implementations are of sufficient quality that the computing industry will use it. Proof of this is that a number of companies have already implemented the JDO 2.0 specification without it's ratification! JDO fulfills important requirements quite efficiently. In my work place we have used it for two web applications so far, and have seen no reason to go the Application server route.

Let's hear it one more time, Let the Market Decide!

btw, if you have an opinion, then tell me what you think...

Friday, January 20, 2006

Java on the up...

Recently, anecdotal evidence has suggested to me that java's influence has been on the wane... Especially given the view in Cape Town, South Africa - South Africa has traditionally been a microsoft land, while in other countries (mostly first world), microsoft is not so strong.

However, according to Tiobe Programming Commity Index, java is the most popular programming language on the internet, not only that, but java also won the TIOBE Programming Language of 2005 award. Go Java!

Based on more anecdotal evidence is done seem as if microsoft is stronger in the developing world than in the non developing world. I do not think that the battle is between microsoft and java but between closed source proprietary and open source public domain. Open source thrives in environments where you have a high number of educated people as well as a high number of people who have the time to devote to developing open source applications. It stands to reason that if you have a high number of people developing open source applications in their spare time, those same people are going to push the adoption of open source in their day jobs, thereby increasing the popularity of open source, and thus java. It might also be true that open source requires a sufficiently large programming population in order to develop, another reason why java is probably more popular in first world countries.

You may be asking why open source does not fit with VB and C# - the answer is simple. You can't run an open source operating system and code in C#/VB. Okay, before you argue that there are IDE's where this is possible, they are not in the main stream developer market.

Monday, January 09, 2006

Eclipse RCP - have got to see this...

Before I point you to the merits of the Eclipse RCP I'll just digress for a moment and say Happy New Year to all those who deem the new year to be on first of January. I hope 2006 brings many epiphanies for you.

But like I was saying, the RCP is a stunning platform to develop on top of. Every piece of your application is packaged as a plugin so modularising your app is simple. On top of that, you get advanced update and management capability out of the box.

If you need a quick demonstration of its power, then take a look at EclipseZone - Why You Should Use Eclipse RCP (In 10 Minutes).

It'll prove to you the merits of developing on the eclipse RCP platform better than any words could.

btw, the link embeds a short movie clip to walk you through the process of creating a RCP app with eclipse. Unfortunately, it does not work in firefox. However, there is a plugin which with one click allows you to open a site in IE. It changes the current tab to an IE tab. Seemless IE integration! A very useful ie plugin.

How important is the programming language?

  Python, typescript, java, kotlin, C#, .net… Which is your technology of choice? Which one are you currently working in and which do you wa...