Malcolm Davis's Blog

The Java DB, or better yet, the JRE DB, is just a RFP item.

Sales and marketing:
Companies routinely add functionality to a product that will never be used by a client. The reason for the un-used features is to meet an entry on a Request For Proposal (RFP). The sales department can then present the functionality to potential clients.

Many times a RFP item is something that multiple clients have requested, but serves little or no purpose. [The absurdity of the RFP are well understood by people that have worked for the Federal government or Fortune 100 companies. After 4 years on the NASA's Space Station Freedom project, I can tell horror stories about the RFP process.]

Choice and discontentment:
Embedded Java databases have existed for years. As Java developers, we have the added luxury of picking the database of our choosing. [Yet, some have argued that all the choices have bred discontentment toward Java.] Microsoft's claim to fame is their one homogenous, well-integrated, do it all environment. Even though Microsoft VisualStudio falls way short of free tools like Eclipse and NetBeans, and the .NET architecture is lacking features like an Object/Relational Mapper (ORM), the developers don't have all those decisions to make, they just make what they have work.

Microsoft:
Microsoft has introduced the embedded database with the release of SQL Server 2005. As it matures, the database will become a standard component of the .NET platform. Microsoft already provides SQL Server Express for free, which can be embedded into application clients.

So, what does Sun do? Introduce an embedded database. Sun has to have that RFP item checked off the list.

As Microsoft has taught us, it is not necessarily about technology feasibility, competences, or merit, but marketing. Microsoft has satisfied many RFP items in name, but not in spirit.

Reality check:
Welcome to the world of reality. When Jon Stewart has a book author on his show, Jon Stewart did not necessarily think the book was a good idea, rather the publisher bought airtime.

I personally think Sun could spend the energy more judicially by cleaning up the Java API of the deprecated code. However, I am not a marketing guy.

Comments

• What's the point of cleaning deprecated code? It does not save space and break compatibility.

  Posted by: gfx on July 20, 2006 at 07:10 PM

• Compatibility? Java 5 broke code.
  A smaller API makes it easier to learn and use.

  Posted by: malcolmdavis on July 20, 2006 at 08:46 PM

• Smaller API? Count the number of deprecated APIs and match that against the overall size of the API. It's insignificant.

  Java 5.0 broke code? What did it break for you? I have yet to find a piece of my code, pre-Java 5.0, that does not compile with Java 5.0.

  This argument of removing deprecated methods is one of the oldest against current Java implementations, and also the most annoying. If Sun was to do that, there would be an uproar because of the amount of work required to make old source codes compile.

  Posted by: gfx on July 21, 2006 at 02:51 AM

• gfx, 1.5 broke a lot of code, as abstract methods were added to abstract classes and interfaces all over the place. As long as you're dealing with jars, you won't notice it much, but if you are building from source (like gentoo does), you have noticed the migration pain 1.5 brought.

  Posted by: robilad on July 21, 2006 at 04:10 AM

• malcolm, if I parse you correctly, you're saying it's just a PR stunt to compete with Microsoft.
  As the world's best HTML widget ever shows (the one in Swing), stuffing unmaintained technology into the platform for the sake of short term marketing benefit is a less-then-brilliant decision.

  If Sun separated the Sun JDK *product* from the official JDK reference implementation, and kept the PR athletics to their own version, I think they'd have an easier time ticking off features from their list.

  Posted by: robilad on July 21, 2006 at 04:18 AM

• Great blog, thanks for showing that less is more.

  Short concise and so obviously correct that it turns all the other blogs on this subject into mere theoretical discussions (to me at least).

  Keep it up

  Posted by: klopperq on July 21, 2006 at 08:37 AM

• There's no need to remove deprecated API.
  I don't believe it makes the platform harder to learn, since the proportion of deprecated API is miniscule. And, if it were a problem, there is a javadoc option to hide it.
  Removing deprecated API would break binary compatibility. New libraries break source compatibility with new abstract methods, which is a pain, but it's a different issue altogether. In any case, two wrongs don't make a right.
  Finally, there is some API marked as deprecated that shouldn't be, such as Thread.stop(). If another, better (one that hostile code being run couldn't prevent, for example, by catching Throwable) way to kill a thread was introduced, fine, I could see it being deprecated. But for now, it's a legitimate method to use if you know what you're doing.
  Sorry for the digression... but if you think about it, one of the best ways to avoid deprecated APIs is to be ultra-conservative about what you publish in the first place. Based on that criterion, stuffing a DB into the JDK seems like a bad move.
  

  Posted by: erickson on July 21, 2006 at 08:53 AM

• The problem with not removing deprecated APIs is that it makes the entire system of deprecation useless.
  It's specifically meant to mark things for future removal, and if that never comes people will just ignore it.
  It's therefore not so much the volume (which contrary to what you think is substantial though not in many APIs excessive) but the principle involved.
  Your example of saying that Thread.stop() should not be deprecated says enough about why deprecated stuff should be removed. That method should never have been included because it's dangerous, yet people continue to use it because the refusal to do so despite deprecation and giving the (very valid) reasons for it has caused them to believe that deprecation warnings can safely be ignored and deprecation has no reason to it other than to annoy them.
  I do agree that API design should be exremely conservative, and that stuffing a DBMS into the JDK is a bad move (in part because of that).

  Posted by: jwenting on July 24, 2006 at 12:06 AM

• You can categorize the systems like more convinient to use or more efficient. Sun makes more efficient systems and working out to make them more convinient too. user should not frustated while using your technology thats the point?
  

  Posted by: kkkansal on July 25, 2006 at 11:25 PM

• The problem with not removing deprecated APIs is that it makes the entire system of deprecation useless.

  It's specifically meant to mark things for future removal, and if that never comes people will just ignore it.

  It's therefore not so much the volume (which contrary to what you think is substantial though not in many APIs excessive) but the principle involved.

  Your example of saying that Thread.stop() should not be deprecated says enough about why deprecated stuff should be removed. That method should never have been included because it's dangerous, yet people continue to use it because the refusal to do so despite deprecation and giving the (very valid) reasons for it has caused them to believe that deprecation warnings can safely be ignored and deprecation has no reason to it other than to annoy them.
  

  Posted by: gagabi on December 28, 2006 at 02:09 PM

This work is licensed under a Creative Commons License.