The following image is available on the Oracle website currently (original URL):

For me personally the 2 biggest questions about the whole deal have always been What happens to MySQL? and What happens to Java?

MySQL has always been open source and Java has been creeping slowly towards open source over the last few years.

Can Oracle really kill either of these technologies if they chose too? Probably not outright, but they could certainly damage their reputation and community support. People can fork code bases and start again, but it would take time (many years) to build back up to the flagships they are today.

The above image from Oracle is interesting in that it does call out MySQL but does not mention Java at all.

Perhaps Oracle sees more value in MySQL than Java and is attempting to protect it better. Or perhaps Oracle believes Java needs less protection than MySQL, after all, much of the debate over the Oracle/Sun deal has surrounded MySQL and not Java.

Wednesday is the day when some of these questions will hopefully begin to answered.

Why do you think Oracle called out MySQL and not Java?

It’s official: the European Commission has granted regulatory approval for Oracle to acquire Sun Microsystems for approximately $7.4 billion, without further conditions. In a statement released moments ago, Oracle says it expects unconditional approval from China and Russia as well and intends to close the transaction shortly.

Robin Wauters @ TechCrunch
EU Approves $7.4 Billion Deal Between Oracle And Sun

Recently I have been doing some research on tweaking websites to make them faster (either in reality, or at least in appearance to the client). Specifically the research has been focused on the actual client tier interaction – requesting the page, downloading the assets and rendering the page in the browser. In this post I will document some of the better resources I have found, focusing on client-side tweaks, so these resources should be relevant no matter if you are a Java, PHP, .Net or any other flavor of developer.
Continue reading »

Coding styles are THE religious debate of the Software Engineering industry. Everyone has an opinion, but no one has an iron clad argument as to why their ideas are better than someone else’s.

It doesn’t matter what language you write your code in or what company your work for or even what open source project you contribute too, the topic of coding styles will sooner or later raise its head. The debate can range from the banal, like which line the curly brace goes on, to the overly subjective, like how to name variables.

In the end most of the decision points are pretty subjective and it is somewhat irrelevant what you choose, as long as everyone agrees and you are consistent. But don’t be mistaken, a consistent coding style is an important consideration on any project, from the solo developer to the multi-national team.
Continue reading »

We are bombarded with hype about new versions of tools (like IDEs), or new libraries (like a new JDK), or a new software package (like a new object-relational mapper) all day long. But do we even need them? Can’t we basically create what we need to complete these mundane everyday tasks with the tools we already have? Aren’t most of these new releases just a way to sell new software licenses? Even when it comes to opensource software, upgrading to a new release has an inherent cost that needs to be weighed.

Here is a real world example. I am currently invovled in a project that involves upgrading the code base from JDK 1.4 to JDK 5 as part of the scope. My Engineer brain says that this upgrade is not only necessary, but just a plain good idea. There are some new language features in JDK 5 that we can take advantage of, so there is a benefit. But what are the costs? There is definitely a cost involved in doing an audit of the existing code and seeing if there is any code that is incompatible with the new JDK and putting together a plan and effort estimate to address those issues. There is also a optional cost of retrofitting the existing code to take advantage of the new language features (like enums for example). There is a learning curve cost. Perhaps there is a confusion cost for some junior engineers (I am thinking of the autoboxing feature). There is a cascading cost that we now also have to consider upgrading our application server environment to support the JDK 5 code.

So is all of this cost worth it? Will the benefits outweigh the risk and give the company some kind of ROI? I think in most cases, the answer is actually a defiinite yes.

Take the Java 5 upgrade example. Apart from the obvious technical benefits, there are a whole host of trickle down posiitve benefits. For starters, I think many companies underestimate the importance of keeping the geeks happy. Engineers like to use new tools and stay on the cutting edge. They like to be able to read articles in the latest journals and be able to apply the lessons learned straight away. Happy Engineers are good employees. They are more productive. They are more collaborative. They tend to not be looking quite so hard for that next dream job. They tend to be more forgiving of working conditions that might not be ideal. Engineers are creatures who like to learn and keep learning. Working on the same code and project and tools for year after year will be the death of an Engineer and you will end up with just mediocre Coders left on your team as the Engineers will be long gone.

So before you decide on your next upgrade, think about all of the costs involved, there are many hidden ones you may overlook at first glance. But then make sure you also think about all of the benefits (both short and long term). Not every upgrade will make sense, but I bet that a majority of them will.

Not everyone is working on projects for the Defense Department where milliseconds could mean the loss of thousands of lives.

And not everyone is working on the backend for the stock exchange.

And most people are not writing their own application servers from scratch.

What are most people working on? Well that is a little hard to quantify, but it is a pretty safe bet that it is not a sexy application that they are bragging to their friends about. If you believe the 80/20 rule (and I do), most people are actually working on maintenance activities more than inventing something new from the ground up. Those who are inventing things from the ground up are more likely to be building a .com site for their company to show off their wares – it might even have an element of ecommerce to it, but then again, probably not.

So we are bombarded with hype about new versions of tools (like IDEs), or new libraries (like a new JDK), or a new software package (like a new object-relational mapper). But do we even need them? Can’t we basically create what we need to complete these mundane everyday tasks with the tools we already have? Aren’t most of these new releases just a way to sell new software licenses? Even when it comes to open-source software, upgrading to a new release has an inherent cost that needs to be weighed.

Here is a real world example. I am currently invovled in a project that involves upgrading the code base from JDK 1.4 to JDK 5 as part of the scope. My engineer brain says that this upgrade is not only necessary, but just a plain good idea. There are some new language features in JDK 5 that we can take advantage of, so there is a benefit. But what are the costs? There is definitely a cost involved in doing an audit of the existing code and seeing if there is any code that is incompatible for the new JDK and putting together a plan and effort estimate to address those issues. There is also a optional cost of retrofitting the existing code to take advantage of the new language features (like enums for example). There is a learning curve cost. Perhaps there is a confusion cost for some junior engineers (I am thinking of the autoboxing feature). There is a cascading cost that we now also have to consider upgrading our application server environment to support the JDK 5 code.

So is all of this cost worth it? Will the benefits outweigh the risk and give the company some kind of ROI? I think in most cases, the answer is actually a defiinite yes.

Take the Java 5 upgrade example. Apart from the obvious technical benefits, there are a whole host of trickle down positive benefits. For starters, I think many companies underestimate the importance of keeping the geeks happy. Engineers like to use new tools and stay on the cutting edge. They like to be able to read articles in the latest journals and be able to apply the lessons learned straight away. Happy engineers are good employees. They are more productive. They are more collaborative. They tend to not be looking quite so hard for that next dream job. They tend to be more forgiving of working conditions that might not be ideal. Engineers are creatures who like to learn and keep learning. Working on the same code and project and tools for year after year will be the death of an engineer and you will end up with just mediocre hackers left on your team as the engineers will be long gone.

So before you decide on your next upgrade, think about all of the costs involved, there are many hidden ones you may overlook at first glance. But then make sure you also think about all of the benefits (both short and long term). Not every upgrade will make sense, but I bet that a majority of them will.