On Thursday 17 November 2005 02:45, [EMAIL PROTECTED] wrote: > Michael Segel wrote:
> > I know developers want to create applications and deploy them with > pre-built databases on multiple platforms. For them, just the fact that > "it seems to be working today" isn't good enough - they need a statement > that this is a Derby feature they can rely on. > Well, yes. The crux is that the issue lies not within Derby, but within the JVM which is going to have vendor specific characteristics. I did a check and found that Java.io.* classes write high order byte first for numeric values. Since we're dealing with a virtual machine this should be consistent across all platforms and should guarantee compatability. [Note: The only potential danger is if you're writing something to a file and you're on hardware that is natively "little-endian" and you're doing cross langugage app development. (This is actually easy to solve, but you need to be aware of the potential danger.)] With respect to the mainframe, there is an issue of backwards compatibility. I believe that the latest release of zOS does support Unicode. But you still have corporations running OS/390 and prior releases of zOS. It may take 2-3 years before some firms even consider migrating to Unicode on their mainframe, if at all. Even mentioning USS to the big iron keepers makes them nervous... ;-) The net net is that the cost of migrating from EBCDIC to Unicode on the mainframe is not going to be done overnight, nor will it be cheap. My point is that while for the most part you have true platform independence, you will always have issue with the big iron... but again its the JVM and you can always take it up with IBM... ;-) > Then they won't end up calling something a bug just because it doesn't > behave the way they think it should. (They would call it a bug since it > violates the Derby charter. ;o) Ok... :-P Bug is such an over used term. But we have a larger issue at hand. Looking at Derby's Jira, there are over 300 open issues. I did a quick scan and picked out a couple. DERBY-396, DERBY-616, DERBY-713 a clone of DERBY-47 Now which of these are bugs? DERBY-396 asks for the addition of standardized ALTER support to tables. Is this a bug because its saying that Derby doesn't comply with the ANSI standard? Is this a CRITICAL issue? Then looking at DERBY-47 and DERBY-713. This is a bug. This is critical. This is something that shouldn't be too difficult to fix. (Why anyone would take an IN (xxx,yyy) and add the BETWEEN to make it a range is beyond me... Were this an actual commercial product, this would be a "drop everything and fix this" priority. The point I'm trying to make is that if we look at JIRA there are over 300 open issues and the classification of what is critical and what is a bug are subjective. There needs to be guidelines. While DERBY-616 may be a bug, I wouldn't call it critical. This is important because for Derby to be a success, you need to have a realistic priority of what needs to be fixed or enhanced. And while Scott may have volunteered to fix #396, there are some design issues which need to be addressed that go beyond the scope of this one entry. How are these being addressed? They clearly aren't bugs or feature requests... Sorry for the long post, but I wanted to give some concrete examples of the importance in understanding what constitutes a bug... -- Michael Segel Principal MSCC
