Home

News: Java DB is bundled in Mustang

  1. Java DB is bundled in Mustang (49 messages)

    David Van Couvering has written that "Java DB is bundled in Mustang," meaning that users who use Java 6 will have a full relational database as part of the JDK (not, it should be noted, the JRE). However, one has to ask: why JavaDB, instead of the much smaller HSQLDB or One$DB? Considering that derby.jar is 2MB (not including the tools and network client code, which adds another half meg) is it worth it? Is Derby's implementation of SQL - basically a Java port of DB2, for all intents and purposes - the "right one?" Would you rather have seen a more Oracle-like implementation, or perhaps nothing at all?

    Threaded Messages (49)

  2. As you point out, this is 2MB for the JDK, not for the JRE. I cannot imagine a developer truly caring about an additional 2MB in a download. The upside to the JavaDB inclusion is that this will make Java much more accessible for "newbies"... with a JDBC compliant database as part of the base, there is much less to install and configure before being able to start writing non-trivial application. --JohnR
  3. +1 for nothing at all. Oh, and Derby isn't really a port of DB2 at all.
  4. +1 for nothing at all.

    Oh, and Derby isn't really a port of DB2 at all.
    +1 (They are going totally crazy)
  5. Oh, and Derby isn't really a port of DB2 at all.
    Of course. It's a release of Cloudscape. But it's still marvelously DB2-like, which is why I said "for all intents and purposes," and more people are going to know what is meant by being like DB2 than Cloudscape.
  6. uhh, What?[ Go to top ]

    bundle a database with the jdk. Are they nuts. So now SUN is trying to bloat the standard JDK? How about make 2 versions. A simple one for those who aren't newbies and a bloated package for total newbies with a ton of crap. but I wonder how blunding a ton of stuff makes it easier for newbiew. does that make any sense? peter
  7. Compete with Microsoft[ Go to top ]

    bundle a database with the jdk. Are they nuts. So now SUN is trying to bloat the standard JDK? How about make 2 versions. A simple one for those who aren't newbies and a bloated package for total newbies with a ton of crap.

    but I wonder how blunding a ton of stuff makes it easier for newbiew. does that make any sense?

    peter
    Think about it from a client-side software perspective. Let's say you have 5 desktop Java applications that require an embedded database (or use one to work in a serverless mode). Do you want to download 5 different jars containing different embedded databases, or do you want one standard one? Of course developers still have the option of using another embedded database, or another version of the included database, but eventually they'll stop doing it. MS provides this type of functionality with the OS (I think, or is it just so many apps use it that it gets installed right away?). It's important for many desktop apps. Making users install an embedded database with every application that uses one is a pain. So I presume there will be a standard additional module that can be installed with the JRE that contains the database. While I can see the logic, I'm not sure I agree with it. Picking a database implementation seems like picking sides. SQL dialects have all sorts of variations, and if this works the variant bundled may become the preferred one for Java.
  8. Re: Compete with Microsoft[ Go to top ]

    Think about it from a client-side software perspective. Let's say you have 5 desktop Java applications that require an embedded database (or use one to work in a serverless mode). Do you want to download 5 different jars containing different embedded databases, or do you want one standard one?
    This doesn't make any sense. By your logic, I'd be upset that I had to download 5 desktop apps in order to get 5 desktop apps. What does the user care what libs come with each app?
  9. Re: Compete with Microsoft[ Go to top ]

    Think about it from a client-side software perspective. Let's say you have 5 desktop Java applications that require an embedded database (or use one to work in a serverless mode). Do you want to download 5 different jars containing different embedded databases, or do you want one standard one?


    This doesn't make any sense. By your logic, I'd be upset that I had to download 5 desktop apps in order to get 5 desktop apps. What does the user care what libs come with each app?
    Let's say each desktop app if 5 megs + 2 for the embedded DMBS, for a total download of 35 megs. If the DBMS is "standard" and only downloaded once, the total download size reduces to 27 megs. ...but I think it's more about providing the entire kitchen sink in some standard form within Java.
  10. DB only in JDK, not JRE[ Go to top ]

    Let's say each desktop app if 5 megs + 2 for the embedded DMBS, for a total download of 35 megs.

    If the DBMS is "standard" and only downloaded once, the total download size reduces to 27 megs.

    ...but I think it's more about providing the entire kitchen sink in some standard form within Java.
    The Java DB is only in the JDK, not in the JRE that end users typically have on their machine. So you still need to bundle the Java DB for end users because you can't rely on them to have the Sun JDK - they could also have the IBM JDK or a JRE. Karsten Silz
  11. Re: DB only in JDK, not JRE[ Go to top ]

    Let's say each desktop app if 5 megs + 2 for the embedded DMBS, for a total download of 35 megs.

    If the DBMS is "standard" and only downloaded once, the total download size reduces to 27 megs.

    ...but I think it's more about providing the entire kitchen sink in some standard form within Java.


    The Java DB is only in the JDK, not in the JRE that end users typically have on their machine. So you still need to bundle the Java DB for end users because you can't rely on them to have the Sun JDK - they could also have the IBM JDK or a JRE.

    Karsten Silz
    If they put it in the JDK and don't either include it in the JRE or provide a magic way for the JRE to acquire it when needed then the inclusion of it in the JDK is mildly destructive because it makes something feel like it is readily available when it is not. My guess is this is either half baked, half announced, or both.
  12. Re: Compete with Microsoft[ Go to top ]

    Let's say each desktop app if 5 megs + 2 for the embedded DMBS, for a total download of 35 megs. If the DBMS is "standard" and only downloaded once, the total download size reduces to 27 megs. ...but I think it's more about providing the entire kitchen sink in some standard form within Java.
    that makes no sense to me. if I download a desktop app, it's going to come with it's own libraries. A different app isn't going to know or care you have some other java app installed. If SUN includes a DB, then every "could" use a "standard" DB. I highly doubt that will happen. Frankly that's not a standard in the sense of java standard. It's a defacto standard. I still see no point including a DB in the standard JDK. How many desktop apps need a database and how many apps ship with one? How many serverside apps need an embedded database? Even if someone uses the defacto DB in the JDK, what's to say that is usable in a production environment? newbie programmers should have to take time to learn things and understand how things work. Lowering the standard so retards can code Java is nonsense. I'm sure plenty of people will disagree. Lots of business people keep saying, "this should be easier, so that anyone can build a world class app." Well, that's like saying "building the golden gate bridge should only take 6 months and anyone should be able to do it." Just about every project I've been on that was bad (ie poor quality) was due to management's focus on "get the code out now, forget about the bugs". Including a DB in the JDK smells rotten to me. peter
  13. Re: Compete with Microsoft[ Go to top ]

    If the DBMS is "standard" and only downloaded once, the total download size reduces to 27 megs.
    Again, the measure unit for features is not the weight (gross). That's for apples, potatos etc. Guido.
  14. Including a DB with the JDK sounds good to me. For ~2MB it delivers a lot functionality and ease of use for those who develop DB applications.
  15. feel like a nitch to me[ Go to top ]

    I have no statistics to back up my bias opinion, but how many people use embedded database? I use several different databases, so it feels rather pointless for what I do. I can see Sun's reasons for doing it, but it would be nice to include a light version of the JDK without all the junk I don't need or want. peter
  16. Cool... but useless[ Go to top ]

    I beleive it's cool... The JDK is already pretty large and 2MB is not that much. However, why bundle it with the JDK and not also the JRE! This does not make sense. Do they want to make a DB availlable or not! If it's included in the JRE, then it would make more sense as we would be able to assume that it's there and use it, without the need to bundle it with our application. I don't see the advantage of only including it with the JDK as free Java DB are easilly downloadable. So either do it for both or don't do it!
  17. Re: Cool... but useless[ Go to top ]

    I beleive it's cool... The JDK is already pretty large and 2MB is not that much.
    Oh yeah ! Unfortunately, we are not selling apples and it is not a matter of weight. It is called separation of concerns. SUN is becoming as MS that bundles almost everything with the "Operating System" ? In another post there is a sentence about "standard database". But, really, what is going on ? Guido
  18. Object persistence ?[ Go to top ]

    Is this a reaction to MS LINQ ? In that case I think it is very poor. Adding just any JDBC database just doesn't improve the JDK package by one bit. Besides, Derby is not the fastest database for embedded use, as this benchmark shows: http://www.polepos.org I think the people at Sun should really think about the future of object persistence for Java and how they can integrate it with the language in a typesafe and clean way. Microsoft has set a strong example with LINQ and Java is falling behind. We ( http://www.db4o.com ) try to show how simple object persistence can be. Technically it is very easy to store any plain object and to use the Java language for querying in a compile-time-checked and typesafe way. Is there noone at Sun that sees how important it is to make developers as productive as possible?
  19. Re: Object persistence ?[ Go to top ]

    I think the people at Sun should really think about the future of object persistence for Java and how they can integrate it with the language in a typesafe and clean way. Microsoft has set a strong example with LINQ and Java is falling behind.

    We ( http://www.db4o.com ) try to show how simple object persistence can be. Technically it is very easy to store any plain object and to use the Java language for querying in a compile-time-checked and typesafe way. Is there noone at Sun that sees how important it is to make developers as productive as possible?
    There is already an excellent and simple specification for general-purpose object persistence in Java. It includes the ability to persist to a wide range of stores, relational and non-relational. It has several high-quality high-performance implementations and a recently released open source version. It is called JDO. I don't consider the ability to have typesafe querying that important, as for any well-written application using transparent persistence the actual query should be a very minor part of code. In fact, I consider that such typesafe querying may be a disadvantage, as it prevents easy optimisation (such as hand-tuning of externalised queries outside of an application, or switching query languages simply by changing configuration). It also encourages too much to be dependent on language syntax - I can currently use JDO from almost any langauge on the JVM that can call Java libraries and define classes. The only thing lacking as far as I can see is the ability to query in-memory objects, but there is no reason why a JDO implementation should not provide that.
  20. Is this a reaction to MS LINQ ? In that case I think it is very poor. Adding just any JDBC database just doesn't improve the JDK package by one bit. Besides, Derby is not the fastest database for embedded use, as this benchmark shows: http://www.polepos.org
    OK how long must we suffer being shoved in our faces the craptastic, incredibly unprofessional polepos piece of sh*t? Common sense, please. Thank you.
  21. I think the important question isn't "why Derby rather than something else?", but "why bundle a database into the JDK?", which for many people is equivalent to the JRE in how they use it. (Raise your hand if you've installed the JDK on a production server so you'd have the tools ready if you needed them locally in the event of a problem...) I think this will lead to confusion and questions about what the standard Java platform really is. Developers will take it for granted that the DB functionality is present in Java, and their apps *won't be portable* to a JRE or a JDK from another vendor, like BEA, IBM, Apple or Apache Harmony (when it's ready) that don't include it. What's worse, because this is done outside of the supervision of the Java SE expert group, there are no standardization forces. Apache Derby is an Apache project. Derby then has the potential to change. How will Sun ensure that Derby is predictable in subsequent versions of the JDK? I can think of two ways - Sun would either have to ship an old version, or fork it. Neither is appealing. I hope they have a plan for this. I think they should reverse course and instead create a well-integrated, -documented and -supported JDK add-on, a "Developer Productivity Package" that could be installed easily, on-demand and directly (think 'apt-get'). By making users take deliberate action to get it, I believe it would make it clear that the functionality is an addition to the standard platform functionality, and therefore less confusing. That would achieve the stated goals, and help preserve the "normalized functionality" that we all depend on in the Java SE platform. geir
  22. I think the important question isn't "why Derby rather than something else?", but "why bundle a database into the JDK?"
    The real question is "where is JCP in this decision?". I hear it often from Sun that Java is getting more and more open, but if Sun can bundle whatever they want in the JDK then what kind of openness is this? I think Sun is free to create a JDK+NetBeans bundle (as they have done it before), but things like javac or javadoc or a built-in db are percieved to be part of Java. We, the java developers, expect to see these built-in tools in every JDK, we think these are part of Java. Can you think of Java without javac or javadoc? These tools are not governed by JCP but are effectively part of core Java. Btw, why stop at the db? Add a few built-in servers too! And it actually makes sense. If the intention of this bundling was to make newbees happier, and since we know that most of these newbees are using it in the server side, then why not add a built-in app server too? :-) Ideally everyone should be free to make such newbee freindly bundles, not just Sun, just like Linux bundles. Is it possible? Ara.
  23. … I think this will lead to confusion and questions about what the standard Java platform really is.

    Developers will take it for granted that the DB functionality is present in Java, and their apps *won’t be portable* to a JRE or a JDK from another vendor, like BEA, IBM, Apple or Apache Harmony (when it’s ready) that don’t include it.
    JavaDB is only being co-bundled with the Mustang JDK; it is not integrated with the rest of the JDK bits in any way. It’s not on the default classpath. It’s not visible to the Java launcher, javac, or other tools until and unless the developer takes the specific action of adding the the JavaDB jar files to the classpath. An application developed with the JDK as shipped, without these jar files having been added to its classpath, will be just as portable as you expect. For more details and context please see my long post on JavaLobby.
  24. Mark, have read your post on JavaLobby. I now understand the rationale. Thanks for clearing that up!
  25. Mark :
    JavaDB is only being co-bundled with the Mustang JDK; it is not integrated with the rest of the JDK bits in any way. It’s not on the default classpath. It’s not visible to the Java launcher, javac, or other tools until and unless the developer takes the specific action of adding the the JavaDB jar files to the classpath. An application developed with the JDK as shipped, without these jar files having been added to its classpath, will be just as portable as you expect.

    For more details and context please see my long post on JavaLobby.
    I still think that you have the portabliity problem. I take a program that I write for Sun's JDK (and people do conflate the JDK and the JRE), and I can't move it elsewhere without going out and finding the same version of Derby somewhere. Why not just offer an additional "download pack"? geir
  26. JavaDB is only being co-bundled with the Mustang JDK; it is not integrated with the rest of the JDK bits in any way. It’s not on the default classpath. It’s not visible to the Java launcher, javac, or other tools until and unless the developer takes the specific action of adding the the JavaDB jar files to the classpath. An application developed with the JDK as shipped, without these jar files having been added to its classpath, will be just as portable as you expect.

    For more details and context please see my long post on JavaLobby.
    I still think that you have the portabliity problem.

    I take a program that I write for Sun’s JDK (and people do conflate the JDK and the JRE), and I can’t move it elsewhere without going out and finding the same version of Derby somewhere.
    Um, you can just copy the Derby jar files from the $JDK/db directory and include them in your application.
    Why not just offer an additional “download pack”?
    The whole point of this exercise is to make it easy for developers to play with the new JDBC 4 features with the Mustang JDK out-of-the-box. If we don’t care about that goal then we could just point to http://db.apache.org/derby and be done; there wouldn’t be much point in creating some new kind of download artifact.
  27. Mark :
    Geir :
    I still think that you have the portabliity problem.

    I take a program that I write for Sun’s JDK (and people do conflate the JDK and the JRE), and I can’t move it elsewhere without going out and finding the same version of Derby somewhere.
    Um, you can just copy the Derby jar files from the $JDK/db directory and include them in your application.
    What do you want to bet people will put $JDK/db in their classpaths?
    The whole point of this exercise is to make it easy for developers to play with the new JDBC 4 features with the Mustang JDK out-of-the-box. If we don’t care about that goal then we could just point to http://db.apache.org/derby and be done; there wouldn’t be much point in creating some new kind of download artifact.
    If it's really about making it easy to learn JDBC4, why not put together a JDBC "tutorial pack" with JavaDB/Derby, example programs, seed data, a developers guide, etc? Heck, throw in netbeans and some kind of schema designer plugin. Make it really simple out of the box. The issue for me is that this is setting an expectation about what functionality is in the Java platform. We can split hairs and talk about the /db directory or try to make it a discussion about Derby but I think the long-term effects won't be positive. People will confuse what is the platform, and what is Sun value-add. By all means, I think Sun is free to do whatever vlaue-add they want to _around_ the JDK/JRE, but I don't think _in_ the JDK/JRE is a precedent you really want to set. Imagine the howling and gnashing of teeth if some other vendor added SWT to a SDK or a JRE.... after all, it would only be for convenience to help people learn to write better, faster GUI programs in Java. ;) geir
  28. Geir wrote:
    What do you want to bet people will put $JDK/db in their classpaths?
    I’m sure that some people will do that. I don’t see a big problem with it. I think most Java developers are smart enough to realize that by doing so they’d be creating a dependency upon something that’s not part of the standard platform. You disagree; that’s fine.
    The issue for me is that this is setting an expectation about what functionality is in the Java platform. We can split hairs and talk about the /db directory or try to make it a discussion about Derby but I think the long-term effects won’t be positive. People will confuse what is the platform, and what is Sun value-add. By all means, I think Sun is free to do whatever vlaue-add they want to _around_ the JDK/JRE, but I don’t think _in_ the JDK/JRE is a precedent you really want to set.
    So we should remove the wildly popular jconsole tool and the other diagnostic tools that were introduced in Sun’s Tiger JDK? We should remove the apt tool? We should remove the Java Plug-In and Java Web Start from Sun’s JRE? We should remove JDI, the Java Debug Interface, which has been implemented by many other vendors even though it’s an evil, proprietary com.sun API? We should remove all the sample and demo code lest some unwitting developer inadvertently create dependencies upon them? Where does it end?
    Imagine the howling and gnashing of teeth if some other vendor added SWT to a SDK or a JRE…. after all, it would only be for convenience to help people learn to write better, faster GUI programs in Java. ;)
    Sorry, but I don’t buy this analogy. SWT is not an implementation of any part of the Java SE Platform. Derby is an implementation of JDBC 4. If I did buy your analogy then I still wouldn’t find your argument persuasive. In point of fact Eclipse is a kind of SDK—it even includes its own Java compiler—and with Eclipse you can choose—or not—to configure your application in such a way as to depend upon bits provided by Eclipse. Is that so very different from the situation with Derby being co-bundled with Sun’s Mustang JDK? Why is it okay for Eclipse to do this, but not Sun?
  29. Mark :
    So we should remove the wildly popular jconsole tool and the other diagnostic tools that were introduced in Sun’s Tiger JDK? We should remove the apt tool? We should remove the Java Plug-In and Java Web Start from Sun’s JRE? We should remove JDI, the Java Debug Interface, which has been implemented by many other vendors even though it’s an evil, proprietary com.sun API? We should remove all the sample and demo code lest some unwitting developer inadvertently create dependencies upon them?

    Where does it end?
    Do you really classify developer and management tools the same as a relational database, a piece of application infrastructure to which applications are tied?

    Imagine the howling and gnashing of teeth if some other vendor added SWT to a SDK or a JRE…. after all, it would only be for convenience to help people learn to write better, faster GUI programs in Java. ;)
    Sorry, but I don’t buy this analogy. SWT is not an implementation of any part of the Java SE Platform. Derby is an implementation of JDBC 4.
    A relational database is an "implementation of JDBC"? Aren't you confusing this with a database DRIVER?
    If I did buy your analogy then I still wouldn’t find your argument persuasive. In point of fact Eclipse is a kind of SDK—it even includes its own Java compiler—and with Eclipse you can choose—or not—to configure your application in such a way as to depend upon bits provided by Eclipse.
    SDK is a generic term, and yes, Eclipse even *calls* it an SDK. However, it isn't ever considered to be representative of the "the Java Platform" as the Java JDK certainly is. (And yes, it's a reasonably good Java compiler with the added bonus that it can be reused easily, so Apache Tomcat and Apache Harmony use it...)
    Is that so very different from the situation with Derby being co-bundled with Sun’s Mustang JDK?

    Why is it okay for Eclipse to do this, but not Sun?
    What is very different? Eclipse producing a SDK? "SDK" is a generic term, used across all languages, platforms, and has been for decades. Some examples that have nothing to do with Java - Windows 2003 Platform SDK, Google Desktop SDK, Apple FireWire SDK, NVidia SDK, Macromedia Flash SDK, TiVo Home Media Engine SDK... "JDK" is a very specific term. Not only does it mean it has to do with Java I think most developers would concur it's a standard set of tools + a JRE that is the minimum required to build and run Java programs. So sure, Sun is free to create a "Developers SDK for Java" (try and respect the Java branding usage that other members of the community are required to follow, please) and bundle whatever they want. Go for it. It's good for java and good for the community. But the JDK shouldn't be a vehicle for this, IMO. geir


  30. A relational database is an "implementation of JDBC"? Aren't you confusing this with a database DRIVER?

    The JDBC driver(embedded and network client) provided in the 10.2 alpha of Java DB/Derby implements many of the features defined in the JDBC 4 specification. There is benefit in having single download which provides a means of trying out the JDBC 4 features with a version of Java SE. Could you utilize another JDBC driver and backend? Sure, but currently there are not many drivers available which have an EA release of their drivers which provide JDBC 4 support. In the case of Java DB/Derby, you really cannot deliver the JDBC driver without delivering the backend.
  31. Geir:
    Mark:
    So we should remove the wildly popular jconsole tool and the other diagnostic tools that were introduced in Sun’s Tiger JDK? We should remove the apt tool? We should remove the Java Plug-In and Java Web Start from Sun’s JRE? We should remove JDI, the Java Debug Interface, which has been implemented by many other vendors even though it’s an evil, proprietary com.sun API? We should remove all the sample and demo code lest some unwitting developer inadvertently create dependencies upon them?

    Where does it end?
    Do you really classify developer and management tools the same as a relational database, a piece of application infrastructure to which applications are tied?
    It depends upon the scope of the classification.

    Monitoring consoles, annotation-processing tools, and relational database engines—just to pick a few examples—all serve different specific ends, and of course it’s nonsense to say that a monitoring console is exactly the same sort of thing as a database engine.

    More broadly speaking, however, each of these things is a software artifact that’s not a required part of the Java SE Platform but is, nonetheless, useful to developers in the construction of Java applications. That’s why they’re all in the JDK.
    Imagine the howling and gnashing of teeth if some other vendor added SWT to a SDK or a JRE… after all, it would only be for convenience to help people learn to write better, faster GUI programs in Java. ;)
    Sorry, but I don’t buy this analogy. SWT is not an implementation of any part of the Java SE Platform. Derby is an implementation of JDBC 4.
    A relational database is an “implementation of JDBC”? Aren’t you confusing this with a database DRIVER?
    I didn’t mean “implementation” in the narrow technical sense. I meant it in the more informal sense that Derby includes a JDBC driver that’s compliant with the new JDBC 4 specification, and therefore Derby can be used to try out the new JDBC 4 features in Java SE 6. The new JDBC 4 APIs—and indeed all of JDBC—are pretty useless without a JDBC driver and a database engine for that driver to talk to.

    SWT is an alternative user-interface toolkit. As such it may have some value, but it’s not tightly related to much of anything in the Java SE Platform. No APIs anywhere in the platform require SWT or an SWT-like artifact in order to be useful.

    So I still don’t buy your analogy.


    “JDK” is a very specific term. Not only does it mean it has to do with Java I think most developers would concur it’s a standard set of tools + a JRE that is the minimum required to build and run Java programs.
    Hmm, let’s see… The minimum required to run a Java program that uses the JDBC API is a JDBC driver and a database engine for it to talk to. That sure sounds to me like a good argument for including such components in the JDK!
    So sure, Sun is free to create a “Developers SDK for Java” (try and respect the Java branding usage that other members of the community are required to follow, please) and bundle whatever they want. Go for it. It’s good for java and good for the community. But the JDK shouldn’t be a vehicle for this, IMO.
    You talk about a “standard” set of tools. Who defines the standard? As to the “minimum required,” who sets the bar?

    We already have the JCP to govern the definitions of the various Java platforms. The JCP doesn’t govern functionality outside the bounds of those definitions. Every implementor of the SE platform is free to add proprietary features to both their runtime environments and their SDKs, and every single one of them does so.

    So either (A) Sun is somehow special for some reason and, unlike all other implementors, shouldn’t be allowed to add proprietary features to its development kit, or (B) The JCP needs to be extended to govern the contents of all Java SDKs and all vendors will have to ship pure, “minimal” development kits, placing any proprietary features in a separate package.

    I don’t think either alternative is tenable.
  32. So we should remove the wildly popular jconsole tool and the other diagnostic tools that were introduced in Sun’s Tiger JDK? We should remove the apt tool? We should remove the Java Plug-In and Java Web Start from Sun’s JRE? We should remove JDI, the Java Debug Interface, which has been implemented by many other vendors even though it’s an evil, proprietary com.sun API? We should remove all the sample and demo code lest some unwitting developer inadvertently create dependencies upon them?

    Where does it end?
    I know Geir already responded to this, but this is just too good not to comment: come on Mark, really, even a junior Java programmer understand the difference between the debugger interface or the monitoring tools and a DATABASE. Really, that was such an incredibly lame comment.
    Sorry, but I don’t buy this analogy. SWT is not an implementation of any part of the Java SE Platform. Derby is an implementation of JDBC 4.
    This one just had me burst into tears. I suggest you send informational letters to IBM, Oracle, Microsoft letting them know that they should change the description for DB2, Oracle DB and SQL Server to read "JDBC3 implementation" instead of "relational database".
    If I did buy your analogy then I still wouldn’t ?nd your argument persuasive. In point of fact Eclipse is a kind of SDK—it even includes its own Java compiler
    But wait, there's more! Deep-fried logic strikes again! Yeah, Eclipse is a JDK just like Mysql is a JDBC implementation, Emacs is a Lisp development toolkit, Nokia N90 is an implementation of Bluetooth. Wow. And to think that all this stuff is coming not from, say, Rolf Tollerud, but from the "Chief Engineer for the Java 2 Platform, Standard Edition, at Sun Microsystems"...
  33. Geir Magnusson wrote What's worse, because this is done outside of the supervision of the Java SE expert group, there are no standardization forces. Apache Derby is an Apache project. Derby then has the potential to change. How will Sun ensure that Derby is predictable in subsequent versions of the JDK? I can think of two ways - Sun would either have to ship an old version, or fork it. Neither is appealing. I hope they have a plan for this. I'm not sure what you mean by "predictable." Do you mean predictable in terms of schedule, features, or the stability of public interfaces? In terms of schedule, Apache Derby community generally plans to have a feature release or maintenance release every 3 months. I don't see how a release that is no more than 3 months old can be considered "old" in any real way. In terms of features, Derby and has a well-defined charter: "Pure Java, easy to use, small footprint, standards-based, secure." Anything that abides by that charter and has the right level of quality generally goes in. Anything that goes against that charter generally is not allowed in. The needs for Java DB in the JDK are very basic, and are completely in line with that charter. So I just don't see that being an issue. In terms of stability of public interfaces, the Derby community has the same level (if not greater) commitment to backward compatibility and not breaking public interfaces as Sun does (I can vouch for this, having been involved in many painful debates on changes and how they affect compatibility), so I just don't see that being a problem either. There are no plans that I have ever heard of for Sun to fork Derby, and I don't think anyone here at Sun even sees that as a viable option. Our development team doesn't even have an infrastructure to do that. Every change we make gets checked in directly to the Apache Derby codeline.
  34. David :
    Geir Magnusson wrote

    What's worse, because this is done outside of the supervision of the Java SE expert group, there are no standardization forces. Apache Derby is an Apache project. Derby then has the potential to change. How will Sun ensure that Derby is predictable in subsequent versions of the JDK? I can think of two ways - Sun would either have to ship an old version, or fork it. Neither is appealing. I hope they have a plan for this.

    I'm not sure what you mean by "predictable." Do you mean predictable in terms of schedule, features, or the stability of public interfaces?
    I wasn't talking about Apache Derby - it's fine. I was talking about how you ensure that the JDK that I install next month on machine A is going to be "compatible" with with the JDK that I download and install on machine B a year later, in the sense now that people will confuse the JDK as providing database functionality. You don't fix bugs in the classlibrary now because of fear of breaking running applications....


    In terms of schedule, Apache Derby community generally plans to have a feature release or maintenance release every 3 months. I don't see how a release that is no more than 3 months old can be considered "old" in any real way.

    In terms of features, Derby and has a well-defined charter: "Pure Java, easy to use, small footprint, standards-based, secure." Anything that abides by that charter and has the right level of quality generally goes in. Anything that goes against that charter generally is not allowed in. The needs for Java DB in the JDK are very basic, and are completely in line with that charter. So I just don't see that being an issue.

    In terms of stability of public interfaces, the Derby community has the same level (if not greater) commitment to backward compatibility and not breaking public interfaces as Sun does (I can vouch for this, having been involved in many painful debates on changes and how they affect compatibility), so I just don't see that being a problem either.

    There are no plans that I have ever heard of for Sun to fork Derby, and I don't think anyone here at Sun even sees that as a viable option. Our development team doesn't even have an infrastructure to do that. Every change we make gets checked in directly to the Apache Derby codeline.
    Again, I'll emphasize that I wasn't worried about Apache Derby being a good open source project producing good software. I'm worried about this confusing developers as to what functionality is standard, and how that functionality, which will then be a de-facto standard part of what people consider to be the Java platform, will be managed patch release to patch release by Sun. I think the ecosystem would have be better served with a "developer pack" strategy. geir
  35. Geir says
    I wasn't talking about Apache Derby - it's fine. I was talking about how you ensure that the JDK that I install next month on machine A is going to be "compatible" with with the JDK that I download and install on machine B a year later, in the sense now that people will confuse the JDK as providing database functionality.

    You don't fix bugs in the classlibrary now because of fear of breaking running applications....
    and
    Again, I'll emphasize that I wasn't worried about Apache Derby being a good open source project producing good software.

    I'm worried about this confusing developers as to what functionality is standard, and how that functionality, which will then be a de-facto standard part of what people consider to be the Java platform, will be managed patch release to patch release by Sun.
    I guess I'm confused. You say Derby is "fine" but then you worry about it breaking compatibility for users. I would think any "fine" database product would guarantee solid compatibility, at a level similar to that expected for the JDK, from release to release, and of course Derby does. That said, if I could summarize your overall concern, it seems to be that (a) bundling Java DB in the JDK, even though it's very clearly a loose bundling (given that you have to explicitly put it in your classpath), might leave the impression that it's part of the "standard platform" and then (b) given that possible impression, it might surprise and upset users if at some point in the future Java DB doesn't rise to the same level of stability and quality as this standard platform. Those are a lot of "mights" and "ifs", and I don't think they justify putting Java DB into a separate download, especially, as Mark has said, when the whole point of the exercise was to provide an out-of-the-box implementation of the JDBC APIs. David
  36. David :

    I guess I'm confused. You say Derby is "fine" but then you worry about it breaking compatibility for users. I would think any "fine" database product would guarantee solid compatibility, at a level similar to that expected for the JDK, from release to release, and of course Derby does.
    In your own blog, you point out the version you will ship now won't be compatible with the version you ship later. You explain that it's becuase it's an "alpha", but that does support my point - software evolves and changes. And Derby isn't under your control. It's an Apache project. Sure, individuals from Sun have been and will continue to be major contributors, but the project community - not Sun - decides where the project goes.
    That said, if I could summarize your overall concern, it seems to be that (a) bundling Java DB in the JDK, even though it's very clearly a loose bundling (given that you have to explicitly put it in your classpath), might leave the impression that it's part of the "standard platform"
    Yes.
    and then (b) given that possible impression, it might surprise and upset users if at some point in the future Java DB doesn't rise to the same level of stability and quality as this standard platform.
    Or more accurately, the functionality present in Sun's JDK v6_x may not be the same as Sun's JDK v6_y or VendorX's JDK v6_z, independent of the JCP process and those trusted by the community as stewards of the technology - the Java SE expert group Isn't predicable functionality defined by the EG the core of the compatibility philosophy strongly espoused by Sun (until this week, apparently)?


    Those are a lot of "mights" and "ifs", and I don't think they justify putting Java DB into a separate download, especially, as Mark has said, when the whole point of the exercise was to provide an out-of-the-box implementation of the JDBC APIs.

    David
    I'd like you to be honest and answer the following question : What are the limits to what can go into a JDK? Are there any? How about SWT? Every argument you made above is just as valid for SWT ("make it easy for developers to play with the new SWT features") because of the "might" and "possibly". What about Mono + IKVM? I've seen microbenchmarks claiming Derby runs faster w/ Mono+IKVM in some tests than on Tiger. There's something that will help developers learn those JDBC4 APIs even quicker! ;) While I was kidding about Mono, I wasn't about SWT and the question - what's the limit here? Should be abandon the notion of the JDK as a standard configurtion of the platform and just let vendors do whatever? geir
  37. In your own blog, you point out the version you will ship now won't be compatible with the version you ship later. You explain that it's becuase it's an "alpha", but that does support my point - software evolves and changes.
    There is a specific flag we disable during alpha, called the "upgrade flag," that is used to disable upgrades of databases created by an alpha release. This is done very clearly and intentionally. That is not the same thing as what we are talking about here.
    And Derby isn't under your control. It's an Apache project. Sure, individuals from Sun have been and will continue to be major contributors, but the project community - not Sun - decides where the project goes.
    Of course Derby isn't under Sun's control, I have been very clear about that (I thought). I personally think that's a great thing. What I was referring to were the policies and intentions of the overall community, not of Sun. Just as some examples, we have an entire suite of tests in Derby dedicated to testing compatibility between releases and making sure upgrades are successful. Any bug that breaks compatibility or upgrade is considered a blocker and must be fixed before we can release. I personally have participated in an effort, off and on, for over a year, with a thread 100s of emails long, trying to find a way to share code between jar files that doesn't break compatibility in the case where a user has a different version of the client jar than the engine jar. The Derby community is serious about this stuff. Yes, it's possible for the project to change direction, and yes, open source does not necessarily have the same strict governance model that an EG has. But my point was more that it is highly unlikely for Derby to have these kinds of issues, not that it is guaranteed.
    Or more accurately, the functionality present in Sun's JDK v6_x may not be the same as Sun's JDK v6_y or VendorX's JDK v6_z, independent of the JCP process and those trusted by the community as stewards of the technology - the Java SE expert group

    Isn't predicable functionality defined by the EG the core of the compatibility philosophy strongly espoused by Sun (until this week, apparently)?
    I am fairly ignorant in the area of JCP policy and intentions, Sun's intentions and philosophy around Java, and so on, so I can't really debate this point with you. I was focusing more on your concerns about the potential perceived expectations of the stability and compatibility of Derby compared to the rest of the JDK. I also think that users will not get confused and think that Java DB is part of the core platform, as you assert. But ultimately this is a matter of opinion, and I suspect we'll just have to agree to disagree.
    I'd like you to be honest and answer the following question :

    What are the limits to what can go into a JDK? Are there any? How about SWT? Every argument you made above is just as valid for SWT ("make it easy for developers to play with the new SWT features") because of the "might" and "possibly".

    What about Mono + IKVM? I've seen microbenchmarks claiming Derby runs faster w/ Mono+IKVM in some tests than on Tiger. There's something that will help developers learn those JDBC4 APIs even quicker! ;)

    While I was kidding about Mono, I wasn't about SWT and the question - what's the limit here? Should be abandon the notion of the JDK as a standard configurtion of the platform and just let vendors do whatever?

    geir
    Again, this is not my area of expertise. I was discussing the issues you raised about the stability and reliability of the JDK versus Derby, as someone who works in Derby. I don't have a lot of strong opinions or knowledge in terms of what should and should not go into the JDK, what the JDK stands for, etc. Thanks, David
  38. I'd rather like a OODB
  39. Perhaps a better option would have been to bundle it with their Netbeans?
  40. Much more important packages like javax.comm are not there, why?
  41. I am not sure if this is good news since it portends more such additions in the future. So now we might have JEE, JSE and now JSKE (Java Kitchen Sink Edition) :) . One option would be for sun to act as a "clearing house" for such components such as derby. They can extend their installer to allow end users to "add components" whose metadata has been published by sun on their "add on repository" site. Thus sun can choose to certify specific versions that they will allow the installer to access and install and which can get supported by sun, but which will actually get maintained by the respective owners. At a future date they can allow an "allows" api / command line parameter which enforces the availability of such components before executing a program. My feeling is this will allow development teams to rely on updated versions of relatively standardised components without Sun having to get into the business of bundling items directly into the JDK / JRE. We already have maven which does similar stuff, and Sun could use the same as a starting point from a conceptual perspective except that dependencies will get checked and resolved at run time and the pom.xml and ibiblio equivalents will be maintained by Sun. Dhananjay
  42. Dahananjay :
    One option would be for sun to act as a "clearing house" for such components such as derby. They can extend their installer to allow end users to "add components" whose metadata has been published by sun on their "add on repository" site.
    I think that we already have a 'clearinghouse', and it's called the Java SE Expert Group. They define what Java SE is. It's their world - we just implement it. I think it would be cool to have a separate utillity that easily allows you to fetch things like JavaDB^H^H^H^H^H Apache Derby. Maybe it could just be a tool that uses the various Maven repositories that the community has been working so hard to organize ;) geir
  43. I think it would be cool to have a separate utillity that easily allows you to fetch things like JavaDB^H^H^H^H^H Apache Derby. Maybe it could just be a tool that uses the various Maven repositories that the community has been working so hard to organize ;)

    geir
    I believe this is already happening withing some linux distros that support JPackage. Recent distros emerging from redhat (at least) use the native software packaging infrastructure to install Java stuff, which is at least convening, considering that they have proper uninstall and dependency management. The word goes that Maven is an abomination, and based on my (limited and unfortunate) experience with it I tend to agree.
  44. The only comment I have is why? The extra 2 - 2.5Mb isn't going to add much to the download but why do it all and then why bundle it in the JDK and not the JRE. All this will do is make deployment more complicated, since as a developer I can not assume that the client will have the Derby.jar installed. This is probably too late for Mustang but for Dolphin, I'd like Sun and the JCP to distribute a "core" JDK and JRE and then allow developers to choose which JDK and JRE extensions to add.
  45. This is probably too late for Mustang but for Dolphin, I'd like Sun and the JCP to distribute a "core" JDK and JRE and then allow developers to choose which JDK and JRE extensions to add.
    But surely that is the situation now. You download the core, then you can separately add extensions like JAI,JMF,JavaMail... The question is what is 'core'?
  46. The reason it is part of JDK is that it is meant for development. A production system may (and will) use a different (better) database.
  47. For demos only?[ Go to top ]

    Well, in the past cloudscape was bundled so that all the example apps could be run without any special DB configuration, which is nice. It's the same reason they package up a servlet engine with the EE JDK. If I want to try out the JSF spec or EJB 3.0 I'd like to kick off the examples without having to build some database schema first. It allows you to focus on learning the "Java" part and leave the integrations till later. I don't see a problem with bundling a small database with the developer kit, they've done it in the past and nobody lost any clients over it. I doubt that Sun is trying to market this database or push it as any kind of "standard". If you don't want to use it then don't. For the elitists who say there should be a "special" download for all the newbies I say get off your pedestal. We are all newbies to any new spec that comes down the pipe.
  48. Considering the fact that Derby is DB2'language compatible, it's easy to guess what influencers of this decision expect the direction of migration to a "production-grade" database would be. Why is that I think it won't be Oracle? Actually, this reminds me building-in Apache's Xalan (IBM born) with horrifying StringBufferCache that essentially made all XSL transformations synchronized and impossible to use in multi-threaded environments. Sure everyone knows what Sun has to do with Java, so do I :) Don't bundle Derby with Mustang! Regards, Slava Imeshev
  49. Bundle Maven instead![ Go to top ]

    If Sun wants to make it easy for developers to download and use an Apache product - like a database - then why not bundle Maven instead? Then show newbies how Maven can be used to download specific versions of the derby database. Sun should also embrace Maven as a way for developers to download Sun's jars as well.
  50. If Sun wants to make it easy for developers to download and use an Apache product - like a database - then why not bundle Maven instead? Then show newbies how Maven can be used to download specific versions of the derby database.

    Sun should also embrace Maven as a way for developers to download Sun's jars as well.
    +1 funny