Fuggedaboutit!
As I mentioned last week there are some obvious stress points in the Oracle/Sun merger - support being on top of the list. Among the personal emails responses I got to this - often, by the way, from people turned off by the mudslinging, spamming, and general off topic idiocy that a few immature fools insert into the public discussions here - the most common theme was that my perception of this is wrong: that the big merger issues aren't in support, but in trying to reconcile the way the two companies used, managed, and sold java and java products.
I disagree - I think the java stuff may generate a lot of heat and smoke but won't, in the end, have much impact on how the merger works out for shareholders, customers, and employees.
On the practical side the reason for this optimism is simple: Oracle has long history of continuing to sell and support competing products coming in with acquisitions. Basically, their attitude in the past has been that if the customer wants to buy A, then the customer gets A - so there's no reason to believe devotees of Sun's java servers won't continue to have access to them even though Oracle already sells alternatives.
On the theoretical side the answer starts with a reality most people want to ignore: the java ecosystem that's grown up around mobile phones, cards, and other smart devices is only marginally related to the java ecosystem that's grown up around enterprise applications - and there's no threat to mobile java here at all.
To understand why I think the right long term answer for java in enterprise applications is to forget about it, you need to understand two distinct supporting beliefs:
And from that, of course, we grew what we've got: an almost perfect reflection of the problem it set out to solve in the form of the most absurdly over complicated and generally unmanageable code metastatis outside Microsoft's own Windows source.
Take a good long look at java as it's used in enterprise applications coming from both Sun and Oracle and you'll see it's all determined by customer response to failures in Microsoft's client-server architecture. Thus Oracle's fusion start-ups are all java -because that isolates their developers from random Wintel change. Similarly, the big java servers - from Sun, Bea, and Oracle's own developers - are all designed to provide fine grained transaction atomicity and control in server environments where that isn't in the OS, and use java to do it because that isolates server developers from operating systems change.
Now customer inertia is a terrible thing - but it is nicely predictable and a great source of the cash needed to sustain change elsewhere. So what Oracle could do with this stuff is to announce enthusiastic support of all things java from both sides of the house - remember there are still people using JCL/COBOL and luddite cash is spent the same way as anyone else's - while quietly putting all of these things on maintenance and pushing R&D toward taking the whole client-server idea out of enterprise applications in favor of relying directly on the hardware and OS software made by the company's platforms division.
Basically, as Oracle goes down the applications appliance path they're not going to need to do any of the things motivating java use in heterogenous environments and so find they can push a lot of today's stiffling complexities down to the hardware/OS level where the customer can, generally speaking, just fuggedaboutit.