Monday, June 28, 2004
J2SE 1.5 Varargs - A solution looking for a problem?
I have blogged previously about inconsequential language features being added to J2SE 1.5. This particular feature plays nicely into that rant. Now, let us look at a boilerplate call using the ubiquitous example of one of the
formatmethod signatures in
java.text.MessageFormat, which creates a MessageFormat with the given pattern and uses it to format the given arguments:
public static String format(String pattern, Object arguments);
which can now be altered to
public static String format(String pattern, Object... arguments);
I will readily admit that this new representation is elegant, to say the least. API users are made aware that this method can take a variable sequence of arguments as its second parameter. That fact isn't hidden in javadocs; the signature itself speaks that out loud. In addition, the API tells you that the method isn't interested in traversing your array or manipulating it otherwise. It is only interested in the arguments you pass. So far, so good.
One can well make the case that limiting the varargs to one per method -- as is the case in 1.5 -- can be restrictive. In such cases, you would have to resort to the current practise of using an array. There is also the issue of backward compatibility or lack thereof. I do not anticipate seeing developers rushing to add support for varargs in code that has hitherto used concise object arrays. It gets worse when you think of overloaded methods that use varargs. It may not be easily apparent which method actually gets called. Sun -- to its credit -- does state this fact:
As an API designer, you should use them sparingly, only when the benefit is truly compelling. Generally speaking, you should not overload a varargs method, or it will be difficult for programmers to figure out which overloading gets called.
In that sense, the new vararg feature speaks to a very small constituency. It comes across as a solution looking for a problem. Of course, I may be missing some merits that more the experienced code cutters will recognize. I am however eager to know what they are, so please use the comment option below.
Update: I forgot to add this thread from the Java forums on "jsr 201 including varargs in public review" from Jan 25, 2004.
Thursday, June 24, 2004
A look at two-phase commits
It is common for enterprises to have applications that simultaneously update data in multiple databases. One can easily visualize the number of moving parts in this setup. In order to deliver on their promise of atomicity, consistency, isolation, and durability (or ACID), transactional systems must ensure data integrity and accuracy by providing some sort of synchronous locking mechanism. Transactions therefore provide the glue that ties one or more of these operations together so they occur in an atomic unit or not at all. To understand two-phase commits, one must have a clear understanding of transactions.
The term resource manager is used to signify an external data store or entity accessed by an application. An RDBMS, a JMS provider or an EIS system, are all examples of resource managers. Typically resource adapters expose the resource manager’s APIs to the J2EE server and applications running on that server. As is immediately apparent, the start and the end of a transaction constitute the milestones that determine a transaction’s boundary or demarcation. When an application begins a transaction, it creates a transaction object. It then involves the resource managers in carrying out the transaction while abiding by the ACID principle. The first call to the resource manager identifies the transaction. All subsequent calls happen under the umbrella of that transaction, until the transaction is signaled as ended. The success or failure of the transaction determines whether the updates are to be committed or rolled back.
In a system with multiple databases (or resource managers) participating in a transaction, each participant must commit or rollback based on the outcome, in unison with the others. And this rule holds even if there is a network failure encountered while connecting to one or more of the participants. Databases and other transactional systems rarely ever get a ‘works well with others’ note in their report cards. Hence there is an inherent problem of who will co-ordinate this transaction, ensuring that each participant does its part. You could go ahead write all this logic [as has been done in the past, and I suspect continues to this day] or you could use a transaction manager. Thankfully the coding habits of chimps are well known and widely documented. J2EE servers provide the Java Transaction Service (JTS) to co-ordinate transactions [surprise, surprise!] Most transaction managers use the X/Open XA protocol to communicate with multiple resource managers in a distributed system. Transaction managers are capable of transparently forwarding transaction context from one component to another as also to resource managers.
And this brings us to two-phase commits. There are two distinct stages or processes [or phases, you might add] that constitute a two-phase commit:
- the Prepare phase where the transaction manager informs all participating databases about the transaction. At the completion of this stage, the transaction manager expects each resource manager to be ready to either commit or rollback their changes.
- Each resource manager in turn returns a success or failure indication. This is the Commit phase, where the transaction manager instructs all participants to commit the transaction. If all resource managers cannot prepare or if there is some kind of failure, the transaction manager asks all resource managers to roll back.
When I started writing this blog, I had imagined it to be my own op-ed page. I have since learnt that opinions by themselves can quickly turn boring. I selfishly hope that entries such that this will help newbie developers understand frequently thrown around acronyms and terminologies better. That’s if the gods at Google are on my side.
PS: A shout out to my buddies from Resource Adapters (RAi). The time I spent working at RAi in the Valley was the most educational contiguous 7 months ever. We did some pioneering J2EE CA stuff and had a penchant for the dramatic!
Sunday, June 20, 2004
As welcome as a turd in a pool
Marvel Comics and Gotham Entertainment Group are introducing a new version of Spiderman regionalized for South Asian audiences. In the Indian version, Peter Parker becomes Pavitr Prabhakar; instead of fighting the Green Goblin he'll battle Rakshasa, a mythical Indian demon. He's wearing a sarong-like garment, and he has unstoppable spiritual powers of asskickage. Link. (Thanks, Robin Pen)
I strongly encourage you to follow the link to Gotham Comics above and see this idiocy for yourself. Unbelievable! First the Tobey Maguire and Kirsten Dunst sleep inducer. Now this. I wonder what Stan Lee has to say about the decline of his creation. I grew up in India and like all the other 80s kids I knew there, I too was into Spidey comics. We watched open mouthed, his every move in the weekly animation series on network television; supreme admiration written large on our faces. We spent many a boring hour at school doodling Spiderman's action sequences in the back of our notebooks. We didn't know Spiderman had a romantic side or a spiritual one. We didn't care! That's why this new avatar of Spiderman is as welcome as a turd in a swimming pool. But maybe its all about pandering. Maybe its all about the money.
Friday, June 18, 2004
How eBay uses J2EE to support 1 billion transactions a day
Thursday, June 17, 2004
Cleaning up my act
- My personal files, papers, and receipts are not neatly filed away.
- I do not live in the geographical location of my choice. It's been a year and a half and all those who've told me "Oh don't worry, Rhode Island will grow on you", were wrong.
- There isn't ample and healthy lighting around me. I have been told the monitor doesn't qualified as a source of lighting.
- I am tolerating some things at my work place I maybe shouldn't. But I am not the first consultant to be the chief cook and bottlewasher at his job. Nor the last.
- My work environment isn't nearly as productive and inspiring as I'd like (or as it used to be).
- I don't back up my hard drive at least monthly. But I doubt I ever will.
- My bed is not made daily.
- I do not live on a weekly budget. But I don't necessarily agree that's a bad thing.
- I do not have a financial plan for the next year.
- I do not have an up-to-date will.
- My earnings are not commensurate with the effort I put into my job. No, I am not overpaid.
- I use caffeine more often than I should. Coffee and water are my two favorite diuretics.
- I eat more sugar than I should.
- I haven't seen a dentist in 2 years. I have a very low opinion of them. To me they rate between single-celled creatures and pond scum in the overall scheme of things.
- I haven't had a physical examination in 3 years.
- Not an eye examination either.
- I don't walk or exercise enough.
- I never tell people exactly what they can do to satisfy me. Okay that sounds wrong but that's how the statement was posed.
- I haven't told my mom I love her, in over 3 months.
Well as Ashley would tell me, this blog entry's as out of place as a one legged man in a butt-kicking contest. I hope you will bear with me on that. But I'm just dying to see what Google AdSense ads accompany this entry!
Tuesday, June 15, 2004
Is this really esoteric?
I came across this on java.net this morning. Some of you regulars may have already seen this. Martin Fowler has written about DiffDebugging which is just a fancy shmancy name for finding out what recent change caused a regression problem. That something like this has been documented -- against the grain of the Agile manifesto -- doesn't suprise me all that much. What does is that java.net gave it frontpage coverage [if you can call it that. I am never sure anymore.] My question is: doesn't everybody already do this? Isn't that the logical starting point? I don't imagine initiating new team members by letting them in on our team's little secret. That's right son, 'round here we use DiffDebugging. Yes, that will be the day!
Friday, June 04, 2004
If you give peanuts, you will get monkeys
Paul Kimmel also provides some reasons why outsourcing of Information Technology jobs will fail in the next few years. I don't agree with his reasons. My take on it is that the quality of life for workers in countries like China and India will steadily improve with higher wages and other benefits. That will lead to an increase in purchasing power and they will now be in a position to own things they couldn't afford only a few years ago. This will start a cycle of higher salaries and higher purchasing. In a couple decades, it is very likely that a majority of these people (not everybody in China and India, mind you, but just these people) will demand exponentially higher wages. At that time it does not make too much economic sense to move or maintain jobs there on the basis of a wage differential.
So will companies bring those jobs back to the United States? Unlikely. Just as manufacturing bases moved from Mexico to China in the 90s, so too will they move from China to elsewhere. It is disheartening that unlike the US, these countries do not have the institutions to bear the brunt of a job exodus. Although, I will concede that IT and manufacturing are two very different beasts. Countries that churn out large numbers of engineering and science graduates do have an edge. In the US, over the years, a number of checks and balances have been created to counter unexpected downturns. India and China do not have any kind of mature medical insurance (universal or otherwise) scheme for a vast majority of their populations. Nor do they have unemployments benefits for their citizens. It is in the US interest to encourage these countries to remedy the situation with a carrot-and-stick approach: "If you want our jobs, make sure your people have some recourse for when we take those jobs away." Yes, there are no free lunches.