That's a good point, I totally agree.

because: - bloating - getting another updatecycle (DB-Update) into the jdk - getting towards an unflexible jdk - "i want to decide which db i use"

Why not keep it in a damn separate project? I hope JDK will not bloat like the .NET Framework SDK. Someone here said why not include it in the JRE; this is even worse.

Couldn't have asked for more. DB integration is good things for small apps with local complex data storage problems

No autoincrement, no digg

How big the JDK will become ?

I think it's a good idea. This step helps developers comforting theselves with Java DB. Eventually, Java DB must of course become a part of the JRE. But why, you may ask. Well, it is true that there may be many alternatives. Possibly even better ones. In the end that does not matter. The important point is that if Java DB is part of the jre it makes life of developers easier as one can be sure to have a database system at ones fingertips. No searching for and evaluating products. Just getting things done. Again, I think it's a good idea. regards Thomas

Of course this is a good thing. Any developer can now easily jump right into developing their database applications without the headache of installing and configuring it first. This was a great idea! Keep up the good work!

OK, so it's in the JDK but not the JRE. So the only use is that developers don't have to download it separately to use it. They still have to bundle the appropriate JARs with their application because the end users, who likely only have JREs wont have it. So what does it give us? The total download size would be the same if we use Derby anyawy - either increase the JDK size by X MB or download X MB separately from apache.org. The only thing I suppose is convenience. Convenience of not having to download an extra binary (i.e. clicking on an extra link). But considering how many things I download anyway for Java development - JDK, Eclipse, various plugins for Eclipse, Maven, etc. what's one more download? So in conclusion I don't care.

I would have stuffed it into NetBeans, or the NetBeans/JDK bundle, or something like that. . But the bundled database doesn't seem very useful on its own in the JDK. The Mustang spec lead may want to consider the advantages of committing himself to keeping the JDK *Reference Implementation* free from APIs and libraries that are outside JCP's specification process, and having a separate product for Sun's own proprietary extensions to the JDK RI.

Seeing as so many (90%?) of developers make their money working on what is basically front-end to a database.. the only questions is: why wasn't this in JDK1.1?

I voted, that, "I don't care". I and don't really, but I did want to layout some things I was thinking.

The only real downside to shipping a DB with the JDK is that it will make it bigger. That's it. That's the only downside. Depending on how big it is, it may not even really matter.

On the possitive side, you would have a capable database shipped with the JDK which every demo app out there could code against. I think that would be nice. If I download the latest version of Spring or Wicket or Grails, it would have demo apps that run against the built-in JDK DB instead of bundling hypersonic or derby. If every JDK had a DB, maybe sophisticated build tools could count on that and fire up a local database that would speed-up builds though a DB cache, or collect stats, or any number of things.

Anyway, I'm not saying that we must have a DB in the JDK, but it it were included, it *would* be well utilized.

-Bryan

Personally, I'd prefer to use the DB of my choice. Free databases are pretty easy to come by these days and I just don't see the logic in adding a DB to the JDK.

Last thing we need is further JRE bloat. Having it in the JDK alone to let developers hack together DB-based apps is fine.

I think that's the wrong way. Besides of the JRE/download size, I think it's really not necessary. Not only do I think that the "market share" of the java db is really small, it all reminds me of the disucssions (and trials) about Media Player & Internet Explorer. Let the developers decide...