Alan WIlliamson's Blog

Tripped up by Apache XML-RPC not encoding the string type

Last night I was plumbing in access to an XML-RPC server from a Java application. I was using the excellent XML-RPC package from Apache for the client. It is a beautifully crafted piece of software, just for the sheer ease of use alone.

However, I came a little unstuck when hitting one particular server. I know the default value for XML-RPC is to assume the type, but this server was looking for it and kept throwing invalid RPC request. This is an example of the output that was passed out to the server:



  blogger.getUsersBlogs
  
    1070485999648
    xxxx@xxxx.com
    xxxx

Which is perfectly legal, even though it doesn't explicitly type the value of the params. Trawling through Google, I noticed this tripping a few others as well. Usually Apache are quite anal about following standards, so it was a bit of a surprise to see this one slipping through the net.

So if you are doing any XML-RPC stuff, watch out for this one, just incase your server's implementation isn't too flexible.

Just had the pleasure of interviewing Richard Monson-Haefel

I have just finished writing up my interview with the well known Java celebrity Richard Monson-Haefel. It was a fun piece to do and I asked him many Java questions including his recent appointment to the JCP Executive Commitee.

One of the refreshing things I discovered was that Richard wasn't scared to point out Java's weak areas and wasn't one of the gung-ho bridgade that thought everything with a Java stamp on it was great. For that alone, I am very comfortable having a man with this attitude at the head JCP table. Java is in good hands.

The interview will be published next month in Java Developer's Journal.

We have Applets, Servlets and MIDlets, we now need CARlets

The mornings trawl through my news items I discover this little gem from WIRED, regarding a quote from Dick Brass, VP of the automotive business unit at Microsoft. They want a Microsoft OS in every car on Earth! WOW, now that sort of ambition even outstrips the number of desktop PCs. Looking at Microsofts site we can see they are talking up the use of .net technology within the automobile market. This is all very interesting and scary at the same time.

Having my car 'net' aware could be very handy, especially for sync'ing up MP3's and various other wee goodies while on the move. Although, this technology is aimed more at the health of the car with respect to oil changes and general servicing. For Microsoft to dominating this area as well scares me somewhat. Already I read that BMW, Toyota, Volvo, Fiat and even my beloved Subaru has Microsoft software running inside.

But I do remember Java having a play in this arena a long time ago. Didn't I see a 'Java enabled' car at a JavaOne? I think I did. I did a quick Google on this, and found this press clipping, regarding a Belgium company that had launched Java software. Their domain sadly goes no where, so lets hope they were bought up as oppose to going out of business. I wonder how far down the road Sun has taken Java.

It would be kinda of cool to have a Java enabled car. We'd need a whole new API and no doubt a JSR to head this up. Maybe we can call it the CARlet. We can load up our small network aware CARlets that can talk with other car users while we pass them. Would make sitting in traffic so much more bearable.

We may be losing the automobile market, but we've at least got a car name with Java in it! Chrysler Java

a well rounded package in Juliet

It was at the end of day#3 at JavaOne and I was tired. I was tired of product pitches, tired of talking, and tired of listening to all the hype. I was collapsed in a chair looking forward to heading over to the JBoss Matrix showing so I could sit in a dark room and not have to speak to anyone without feeling guilty. So it probably wasn't the best time to be coming up to me and trying to pitch me an idea! But someone did! Carlo Walentiny of Infotectonica stepped forward and in a quiet voice give me his standard elevator pitch. I still wasn't impressed or even paying attention I think, but he pushed forward and opened up his laptop to show me a demo of something he called Juliet.

When he opened it up, I woke up out of my trance. I was instantly impressed. I had no idea what the hell it did at that moment because I wasn't really listening before. The GUI wasn't Swing, and it wasn't SWT, it was his own! And man did it look stunning. It was doing some sort of analysis of java code files, which was taken some time. But the way he fed back this wait to the user was not only innovative but useful. It was at this point I was hooked. Anyone that could put as much care to detail as that, deserved my full attention. Juliet is a Java client tool that is used to analyze and navigate through source code and tell you things you never knew! It excels on large code bases and when I tried it on the full source code tree for our BlueDragon I was even more impressed! It gave me back a whole load of useful information such as the number of times a particular method was used, where it was referenced and by whom. I could easily drill down into this information and at each level I was presented with more stats. One of the useful features, was the ability to spot unused methods and constructors. Although some of this information is available through various plugins with many of the IDEs, I found the fact Juliet was standalone a refreshing way to look at my code. I could get myself into the mindset that I was Q&A'ing code and resist the urge to fix small code problems along the way.

One of the really nice things with Juliet is the interface. A lot of thought has gone into this and it is this that won me over to begin with. The way you organize queries and group results together is very slick and its not long before you are presented with a Venn diagram window to ask you how you wish your results to be merged. Very nice touch.

So who or what is Juliet aimed at? It is an ideal tool for anyone that has to review code changes before they are committed to a CVS branch for example. Also very useful for open-source projects where you want to get a feel for the whole source branch as a whole without necessarily loading into an IDE.

If you need to get up to speed quickly on a sizeable chunk of code, then Juliet is the tool for you.

BEA beats IBM in SPECjAppServer2002

After the debacle around the infamous ServerSide report, you could be forgiven for treating all benchmarks and performance comparisons with a pinch of a salt. All the vendors cited in that exercise were very quick to distant themselves from the whole escapade and tout they would only be interested in official benchmarks.

One such body that does attempt to define a standard is the Standard Performance Evaluation Corporation, that lives at http://www.spec.org/. They have a body of tests specifically targeted at Java App Servers, where I believe the tests themselves are all agreed by the major vendors as a true benchmark for testing.

One of the redeeming facets of the setup here, is that each vendor is invited to tune their own systems, so we the reader, can have faith that the best possible optimization/configuration is in place.

A recent set of tests submitted by HP prove interesting reading. This is for BEA WebLogic running with JRocket, on Redhat with Oracle as the database. The hardware, naturally is HP with a dual CPU Intel configuration. With this configuration they are pushing 694.88 total operations per second (TOPS). Okay, a fairly meaningless figure in its own right until you compare it to some other results. IBM, for example, could only manage 448.12 TOPS.

IBM is using WebSphere ontop of their own JVM running on Windows2000, with DB2 as their database. What is interesting to note is that IBM choses to conduct these tests on Windows. You would have thought (especially with their marketing push) that Linux would have been a contender, or even their own AIX OS. One wonders what they know that we don't! When you look at the total cost for each system, the configuration used by HP comes in at $182K where as the IBM setup is $290K! Not only is IBM slower in this instance, but also more expensive.

But before you get too excited, it is worth noting that to date, the only app servers to be submitted for public scrutiny is BEA and IBM. So where are all the other J2EE licensees?

who pays for open-source?

Open-Source is something that is never far from the headlines. It is something that I have been giving a lot of thought to as of late. I haven't resolved my views on the whole movement yet and at the moment, I am purely in a data-collection phase.

The one thing that I have been trying to resolve is the whole notion of food-on-the-table, and who actually puts it there. We all have to eat and if we give away all our hard earned work, then what are we to charge for? This is when the story really gets interesting.

The great belief, as sung by pretty much all companies involved in open-source, is "we charge for support". Okay I can see how that might work, but I am unconvinced. I tried resolving this by looking at examples in other industries of this and I can't find one that sits as well.

We have the mobile operators heavily subsidizing their handsets, practically giving away the lesser models, with the hope that we'll use them more and they'll recoup their money that way. Whether this is working or not is yet to be seen, since a lot of the operators are crippled with the large 3G licenses they had to pay for.

But is there is an open-source model in other industries? What if an airline operated an open-source policy? Flying would be free, first-come-first-served, but the inflight meal (aka the service) would cost $400! Would such a policy work for the airline industry?

What about the automobile industry? Ford would give us all cars for free, but the servicing would be more frequent and be x100 what the typical service is now.

Seems a little farfetched doesn't it? But the thing is, looking at the ticket prices for many of the app-servers, it far outweighs the price of a plane seat.

On one hand, we have the barrier of entry completely removed at zero cost. If we want support and help, then its available to us at a premium. Not everyone will need support mind you, so we have a small minority that will purchase the necessary services. This money will be filtered back down to the company (or developers) that created the software in the first place, so they may put food on their table and continue to develop another day.

But the money they are paying will greatly inflated to compensate for the lack of revenue in the first place. So instead of everyone paying a little, we have a few paying a lot!

Doesn't seem quite right to me.

Don't panic ... you don't need to know everything

I get a lot of private email from readers regarding various aspects of the Java spectrum (and discounting the surge of email from students at the end of the term, looking for someone to complete their final coursework for them) expressing a concern at being left behind.

They are concerned that they aren't keeping up with all the latest developments and find it, at times, overwhelming. Which is a fair comment, looking at the rate we are releasing new revisions, you could be forgiven for panicking.

But the message is, don't. Let things take their natural course and just be aware of current trends. For example, JDK1.5 is about to be thrust into the world, and you'll soon be discovering a whole host of new goodies coming with that. But as a Java developer, don't panic that you don't know every single detail. You are not any less of a Java developer because you don't know the precise in's and out's of say generics.

A long time ago, when Java was still small enough you could keep up-to-date with all the API's realistically, I trotted off to JavaOne. At the time, I wasn't the big-cheese at JDJ but felt that I still had a duty-of-care to know all the latest trends in Java, incase I was asked about something.

I soon discovered that it was becoming impossible to keep abreast of all the developments. I started to panic. But then something happened to me that put the whole thing into perspective and made me sleep soundly at nights again.

I met with James Davidson and walked the show floor together. James at the time, was working deep within Sun (only a few doors down from Mr.Java himself) and was the time the first revisions of the Servlet API was being knocked out. Of all people, I told myself, James will know everything there is about Java; hell he's in the very building its all done. But walking around the show floor, it soon became apparent that he didn't know everything there was about Java. He was like a child in a toy store on Christmas eve, as he discovered new things that Java was being used for. The moment of realization for me was when we clocked the JavaTV API. That was when my (java) life changed.

It was ok to not to know everything and more importantly it was ok to admit to not knowing everything.

My advice to those new in coming to Java, don't try and digest everything. You don't have enough time to do it, and contrary to popular belief, there is more to life than Java. Know what you are suppose to know and know it well.