David Van Couvering 's Blog

Java DB is bundled in Mustang

Well, finally. I've been chomping at the bit on this one for quite a while. I can now officially announce that Java developers will have the convenience of a fully functional, 100% Java database shipping with the Sun JDK. Java DB 10.2 will be available with Mustang (Sun's JDK for Java SE 6) later today or tomorrow as part of the JDK bundles for build 88, available at http://download.java.net/jdk6/binaries/.

Of course this is exciting for me as a developer on Java DB. But I also think this is a great thing for Java developers. Out of the box you have a database that you can build and test against that implements the latest version of JDBC, and which, if you so choose, you can take and deploy your application with, free of charge. And if need support, you can get it.

You will find it under the db directory of your JDK install. You do need to be aware that the version of Java DB that is included in these builds is an alpha version, and that databases you create with this version are not upgradable to the production version that will ship with the GA release of Mustang. But you can start playing around with it and run tests against it starting today (or tomorrow).

As a reminder, this is Sun's redistribution of Apache Derby. There is a web page for Java DB, but all the community work (and we would love you to participate in this community) is done at the Apache Derby web site. We'd love to hear from you. Sign up on the derby-user alias; join the #derby IRC channel; ask questions, give us feedback. The community is very active and you get quick responses from Derby developers and users. It's free, it's open source, and now it's part of the JDK.

Comments

• A really deserved congratulations for you and the whole team behind Java DB (and the Apache Derby project). This is a great news for the Java Community.
  

  Posted by: raulp1 on June 15, 2006 at 06:59 PM

• What makes Derby/JavaDB better than One$DB? One$DB has a lot of similarity to Oracle (e.g. sequence-based primary keys), whereas Derby seems similar to Microsoft SQL Server (e.g. auto increment primary keys). Is it just the licensing that makes Derby/JavaDB better?

  Posted by: briansmith on June 15, 2006 at 10:00 PM

• Bad decision. I've always been against turning the JDK into something it's not meant to be, and including things like databases (and webservers...) into it does just that.
  We're talking a programming language here, not an operating system...

  Posted by: jwenting on June 16, 2006 at 04:26 AM

• How ironic...
  Sun doesn't want to rush into open-sourcing Java for fear of enabling fragmentation with forked codebases. And yet, here we go, creating a fork of a standalone product...
  The way XML/Web Services have been rolled into the JDK over the last few versions has caused all sorts of deployment and development headaches, concerning API differences, classloading, and other sorts of conflicts.
  In the same way, Rhino/JavaScript has also been bundled with JDK 6, and that too is another fork (if I remember correctly, the excellent language-level E4X XML support was ripped out, so it's not the same as "proper" Rhino, and now there's talk of adding XML language-level support into Java 7).
  Has anyone read any of the huge number of posts concerning code bloat in the JDK..? A ready-to-use database that you don't have to download could I'm sure be useful in some contexts (I too could benefit), but not in others (I too could lose), and I imagine creating a database from an applet or webstart would be a security issue too, so I don't see much gain in terms of simplified deployment either...
  - Chris

  Posted by: chris_e_brown on June 16, 2006 at 04:44 AM

• I can understand the JDK, but please tell me this won't be a part of the JRE?

  Posted by: rabbe on June 16, 2006 at 05:04 AM

• @jwenting: "We're talking a programming language here, not an operating system." I think you're mistaken, we're talking about a platform here, that embodies more than just the language itself. But I guess you'd like a jdk with ony the java.lang package included...

  Posted by: hvisser on June 16, 2006 at 05:05 AM

• i think neither Rhyno, nor JavaDB will be part of Java spesifications or JRE. They are just part of Sun JDK, which is only used by developers.

  Posted by: ahmetaa on June 16, 2006 at 05:16 AM

• I agree with others here - work should be in un-bundling the JDK, not adding more to it. Especially not a database. I don't see who this benefits.

  Is adding jars to your application so difficult? Java needs many improvements, but a bundled fork of a database isn't one of t hem.
  

  Posted by: rlinwood on June 16, 2006 at 06:29 AM

• Just a question : why ? As mentioned before Java is to build application and not an application itself ! Putting it in the JRE distributions should be just a great present for Flash Users !

  Posted by: merlino71 on June 16, 2006 at 06:51 AM

• I for one welcome Sun's emphasis on developer friendliness with mustang and including an out-of-the-box database is in alignment with that goal. A large portion of Java applications are database centric so why not throw one into the development JDK for the small cost of 2MB(less when compressed). If you don’t like it don’t use it but at least it is an option for those of us who want it.

  Posted by: aaronanderson on June 16, 2006 at 08:20 AM

• This is good news. Thank you.

  Posted by: johanley on June 16, 2006 at 08:37 AM

• Wow thats a lot of negativity. As for it not being in the JRE. WHAT? How are you supposed to write programs that use this stuff if it's not going to be in the JRE? Now you have to deploy jars you didn't need at development time. How is that useful? I'm sure this is for glassfish and for making applications like “derbytax“ simpler for developers. I don't think this is a fork of derby either. The article clearly points to the Apache Derby website as the central location for changes. So why is it a fork? I like the idea. I think it has a lot of potential on both the client and server side.

  Posted by: aberrant on June 16, 2006 at 08:40 AM

• This begs the question why? The next step will be bundeling a web server, then an app server. This really does not make sense. Especially since you choose a particular db server at the beginning of a project. Including the database with my IDE (Netbeans) is acceptable, but not with the JDK. Most (if not all) developers know where to get their preferred database from, there is no need to include it into the JDK and I believe it is a mistake to do so. Can you please explain the rational behind including the database??

  Posted by: atehrani on June 16, 2006 at 09:05 AM

• Remember guys. These are for the *JDK*, not the *JRE*. These are extra libs for developers to use and include in their apps if they choose to. This is just like how Flash works. The Flash tools come with lots of extra libs that are not included in the Flash runtime. Developers yet to choose what they ship with their apps.

  Posted by: joshy on June 16, 2006 at 09:18 AM

• This is just crap, I think it should be better to make the DB an optional package. So that you can download the jdk with or without the DB.

  Posted by: carmello on June 16, 2006 at 09:59 AM

• To jwenting:

  Remember, Java is not just a programming language. Java is a platform. A database fits nicely into that platform. Maybe you should look at Cocoa on Mac OS X for a comparison, as opposed to C++.

  Posted by: robdaemon on June 16, 2006 at 10:38 AM

• Wow, lots of comments. Let me see if I can summarize some responses:

  - Sorry if I was not crystal clear: Java DB is going into the Sun JDK, not the JRE

  - Java DB classes are not automatically loaded ahead of any other classes. You have to explicitly specify the jar files in your classpath. They are not "special" classes like the java.* and javax.* classes.

  - This is not a fork of Apache Derby. Every change we make is checked directly into the Apache Derby codeline. We don't have our own separate codeline

  In terms of "why"? Well, each person has their own view on this (obviously, from the comments above) and my opinions do not necessarily represent the opinions of my employer, but I think this has great value for developers: out of the box you have a database that you can test your DB applications with and which supports the latest JDBC APIs. I think as a JDK provider this is a great thing to provide our users. But it appears opinions may differ on this matter; ah, well...

  
  

  Posted by: davidvc on June 16, 2006 at 11:12 AM

• First of all, sorry about the formatting of the last comment, I couldn't get preview to work and I had neglected to consider HTML formatting.

  Someone asked why JavaDB over One$DB. Here are the reasons I think Java DB / Apache Derby is the right choice

  
  Support for the latest JDBC spec
  J2EE-compliant database
  Strong SQL standard support
  Licensing - yes, you're right, the Apache license is very amenable
  Strong developer community
  100% Java
  Solid - Apache Derby, in the form of Cloudscape, has been in production and deployment since 1998
  Small footprint
  Embeddable - this has value not only in production but also for developers, as it allows you to write unit tests where you don't have to deal with managing (starting/stopping) the database

  That's not a complete list, but to me those are some of the key benefits.

  Posted by: davidvc on June 16, 2006 at 11:24 AM

• Nice, efficient and surely better. just 2MB???

  Posted by: fachim on June 16, 2006 at 12:02 PM

• Yes, derby.jar is 2MB, can be compressed down to 500K with Pack200

  Posted by: davidvc on June 16, 2006 at 12:32 PM

• davidvc - as far as I'm concerned, your comments have cleared up a lot of confusion, and in this context, it's not so bad, especially concerning classpath and forking worries. Now, if only the folks that embedded Rhino could discuss what seems like a fork with disadvantages, that would be very helpful... but I'm going off-topic.
  - Chris

  Posted by: chris_e_brown on June 16, 2006 at 01:40 PM

• "Out of the box" you have a db, but not a web server and or application server? What goal/request are you trying to fulfill by including Derby? Anyone who is downloading the JDK, should know where and what db to download and install. What about the release schedule difference between the JDK and Derby? Lets say after Java 1.6 JDK release a major defect is found in Derby. Will you create a whole new JDK? This could add more confusion to the JDK release numbers/schedule. The value that you add is very minor to the potential harmfull sideaffects. Developers know how to download databases off the Internet.

  Posted by: atehrani on June 16, 2006 at 02:07 PM

• I know this is a matter of opinion and we could debate this till the cows come home, but personally I think a database is a lot more "core" to developing applications than a web server or an app server, and it is reasonable to have one in your developer kit. Especially one that lets you kick around the latest database APIs.

  I suspect, being in the JDK, Java DB will be held to a higher standard than other database in terms of delivering a compliant and up-to-date implementation of the JDBC API. That has value to developers, IMHO.

  In terms of support, I think it's important to know that Sun can cut a patch release off of the Derby codeline at any point -- it doesn't have to synch up with an official Derby release. The JDK has regular update releases. If there are important fixes for Java DB, then we will drop a patch release into the next JDK update release. We won't need to do unnatural acts with the JDK release schedule.

  
  So I'm not sure there is an issue here. But please enlighten me if you feel I've missed your point.

  Thanks,

  David

  Posted by: davidvc on June 16, 2006 at 03:41 PM

• Wow, this is amazing!! I'm so stoked about this. I flipping out about how cool this is. I'm forwarding this to all my IT friends like NOW. Go Java go!

  Posted by: firefight on June 16, 2006 at 07:58 PM

• This combined with JDBC 4.. man I'm glad I took the Java job. Yeehaw!

  Posted by: firefight on June 16, 2006 at 08:01 PM

• To be consequent you should also bundle javax.persistence and a reference implementation of it.

  Posted by: joerg_wassmer on June 17, 2006 at 01:26 AM

• "Out of the box you have a db, but not a web server and or application server?", says atehrani.Why db and not Webserver or Appserver? The difference is that the JDBC API has allways been part of Java SE. And appart from a useless JDBC-ODBC bridge, there has not been a reference implementation bundled with the JDK. Until now. I think Java DB can serve as a reference implementation of the API that is part of the Java SE spec. As for Webserver or Appserver, they are part of Java EE spec, not SE.
  Peter

  Posted by: 5er_levart on June 17, 2006 at 09:07 AM

• Bundling derby shows that Sun's heart is in the right place - they want to make like better for developers. But the real thing that the Java Platform (tm) needs is a robust software distribution platform that allows any package ( derby, or tomcat, or xalan, or rhino, or spring) to be installed with ease. E.g. we need something like CPAN or jrpm or maven to be distributed with the JDK, not individual packages like Derby.

  http://maven.apache.org/
  http://jrpm.sourceforge.net/

  Seems to me that hosting such a repository would be a good move for Sun, as they could show off that big iron.

  Posted by: javajosh on June 17, 2006 at 02:48 PM

• You are correct that it is more a matter of opinion. I do agree that having a DB that has the latest JDBC spec is nice. But I don't agree that having it with SE makes sense. I can see it with EE. We will just have to agree to disagree at this point.

  Posted by: atehrani on June 17, 2006 at 02:52 PM

• I would prefer to see a real Object Database. This proposed Java DB simply will support the break between languaje, in this case Java and Storage. The only advantage I see is that I don't have to go to Apache Derby website and download Derby from there.

  Posted by: jaquinte on June 18, 2006 at 05:15 AM

• I just don't get why such a piece of software should be included into the jdk?
  I am strictly against a "light"-version of te jre or te jdk, but as it currently looks Sun is on the best way to make users SHOUT for such a feature.
  What will be included next, an completly embeddable spreadsheet framework since users could need it under some circumstances?
  Furtermore tere are tons of open (serious) bugs, but it seems SUN management still prefers to work on duplicating already existing implementations and make te jdk even fatter!

  Be honest, this is just plain stupid. If you want a 100% java database grab it from hsqldb or derby, thats it.

  lg Clemens

  Posted by: linuxhippy on June 18, 2006 at 06:46 AM

• A non-core feature that manages to add another dependency/complication to the Mustang release process--whats not to like? Manwhile for the last decade (and 5 JDK versions) Java SE developers have been cursing Swing and running to apache to download commons-this and commons-that. Excuse me for not sharing in your excitement.

  Posted by: mszefler on June 18, 2006 at 09:18 AM

• Perhaps a better option would have been to bundle it with their Netbeans?

  Posted by: mverbist on June 18, 2006 at 10:47 PM

• I'm a bit confused right now. I thought that Java is the platform and the JDK is the programming language (with several optional plugins). If the jdk is bundled with platform stuff, could I expect all kind of platform things like an development GUI, a text-editor, perhaps even a javadoc-browser?

  And if so, could this mean that the various exams would alter because of the complexity of the platform.

  I think it does belong in a platform, but not in the programming language I love so much.

  I would like to thank everybody for all the efford, but stay focused on the future, on simpleness and a clear separation on platform and language.

  Posted by: marcelloh on June 18, 2006 at 11:51 PM

• Including JavaDB into the JDK is a very interesting (and controversial) decision. I believe it was a good decision. I hope time will show it to be a good decision. Congratulations to the JavaDB team.

  Posted by: nickhomeaccount on June 19, 2006 at 05:51 AM

• " I think you're mistaken, we're talking about a platform here, that embodies more than just the language itself. But I guess you'd like a jdk with ony the java.lang package included... "

  If it's added to the standard API it becomes a de-facto part of the core language. Were it just shipped as a sample (like the SwingSet demo application) there'd be no fuss about it.
  "The next step will be bundeling a web server, then an app server"
  You're behind the times, a webserver is also included in Mustang as part of the core API.
  "I can understand the JDK, but please tell me this won't be a part of the JRE? "
  That would be rather pointless, as it would mean distributing part of the core API with your applications.
  "I suspect, being in the JDK, Java DB will be held to a higher standard than other database in terms of delivering a compliant and up-to-date implementation of the JDBC API. "
  Remember the JDBC-ODBC bridge driver? That was not held to very high standards at all...

  Posted by: jwenting on June 19, 2006 at 06:28 AM

• >>>> " Remember the JDBC-ODBC bridge driver? That was not held to very high standards at all...

  
  The bridge was never documented as a supported product
  http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/bridge.html

  That being said, if you have issues that you would like see addressed in the current version of the bridge, please log a bug.

  Posted by: lancea on June 19, 2006 at 02:43 PM

• this is too much for java core.... db is not really a core... why don't we put a web server there too?

  Posted by: plchung on June 20, 2006 at 02:37 AM

• To the above poster - Java DB is *not* part of Java core - it is part of Sun's JDK which is a development kit - again, Java DB is *not* part of the JRE / Java SE.

  Posted by: forsini on June 20, 2006 at 07:55 PM

• To the above poster again -

  I believe if this is the case, we don't really need a "Sun supported redistribution of Derby".

  Derby is already supported by the Apache Community as open source.. why I need such "special version" of Derby along with JDK 6.

  If there is an Apache Derby bug fixing patch, would you create a patch on JDK ? Yes? No?

  So in this sense if we now need a version of Derby to start development with, we will download from Apache and that's the OFFICIAL place for distribution, and get rid of the JDK Derby at the beginning...

  Maybe some people don't agree, but frankly I believe the things being packed along with JDK should be standalone solely created by Sun only, such as the API, and its reference implementation etc... which Sun is the official source to release.

  Posted by: plchung on June 21, 2006 at 02:06 AM

• Also posted at http://weblogs.java.net/blog/forsini/archive/2006/06/java_db_is_now.html

  This is not a good idea. Why bundle something only a tiny handful of people want or use (or have even heard of) Any useful developer would be able to download the relevant package from the internet in only a few seconds. Surely you must remember the terrible blinding pain caused by bundling bug ridden xml parsers.. why do the same for a database nobody event wants? As a team leader & senior designer at tier 1 investment banks, i fail to see how this benefits the java product or its business users. keep the core package clean, lean and performant.

  Posted by: time4tea on June 21, 2006 at 09:40 AM

• to pichung: In terms of why need a Sun-supported version of Derby. Well, yes, you can get support from Apache Derby directly, but for many folks that's not sufficient. If someone using Sun's JDK finds a bug in the database, they want to be able to call Sun and get it fixed. Really it would be irresponsible of Sun, IMHO, to ship Apache Derby and tell people they have to go to the mailing list and hope someone pays attention to their issues.

  Posted by: davidvc on June 21, 2006 at 09:53 AM

• To time4tea: Java DB is not like the XML parser situation. The XML parser was included in java core, and its classes were loaded automatically when the VM started up. If you wanted to use another XML parser, it was a real problem. That's not true with Java DB. You have to explicitly put derby.jar in your classpath if you want to use it.

  The advantage? Well, now there is a database in Sun's JDK that allows people to exercise the JDBC APIs. Tutorials can refer to it. Demos can use it. It helps people get comfortable with JDBC. It provides early access to the new JDBC APIs. All these things I think have a lot of value to a certain class of developers.

  Since you have to explicitly say you want to use Java DB (opt in, not opt out) I just don't understand what all the fuss is about. It's not like you are being forced to download 500MB of some humongous beast that requires 20 steps to install. It's a couple of megabytes, it is a completely silent install, and just sits there doing nothing until and if you decide to use it... If you're an expert who doesn't need this, fine, but for those folks who are trying to get their hands around this Java thing, I think it has a lot of value.

  Posted by: davidvc on June 21, 2006 at 10:02 AM

• Will Tomcat and Pluto (and maybe Glassfish) receive the same treatment as what Sun gave to Derby? Just for the sake of consistency, I think Sun is going to include lots and lots of optional packages into the JDK... if that is their mean of being developer-friendly and tutorials-friendly and demos-friendly and if they really want to get people confortable with standard APIs other than JDBC.

  Is my logic correct? Is my generalization valid? Please remove the FUD in my mind if I'm wrong. Thanks
  

  Posted by: endlesslove on June 24, 2006 at 02:01 PM

• endkesslove: Sorry, I don't have any insight into the plans for what goes into the JDK.

  Posted by: davidvc on June 26, 2006 at 09:51 AM

• I would prefer to see a real Object Database. This proposed Java DB simply will support the break between languaje, in this case Java and Storage. The only advantage I see is that I don't have to go to Apache Derby website and download Derby from there. usamababy9 - petscremation - coffeematching - shuntong

  Posted by: teamagazine on November 04, 2007 at 11:58 PM

This work is licensed under a Creative Commons License.