You points are understood. But I've always attempted to use a hammer for a nail and a screwdriver for a screw. This extra effort always produces a much cleaner and professional result.
Good clients know that response time is money and resources they spend every day and at every seat. Proper software development is a high cost one time event. I have had occasion to see code I have written running five plus years after implementation. In that time migrated across three platforms. Fred > -----Original Message----- > From: Steve O'Hara [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 22, 2006 4:06 AM > To: [email protected] > Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > > You're right to a certain extent, but the point I was trying > to address > was the ideal of being able to use an SQLite database from a > variety of > toolsets and environments natively. If you've ever written JNI you'll > know why this is a pain and a Java only implementation would be sweet. > > Also, not all SQL engines work the same way and I'm certain HSQLD is > slower than SQLite architecturally, not because it's implemented in > Java. After all, there is a non-free variant of HSQLDB > (HyperXtremSQL) > written in Java by the same author that is 50% faster - he didn't get > that by tweaking the code, more like re-architecting the storage. > > The language is just a tool, a way of describing a solution to a > machine. The judgement of performance etc of a language is a little > specious because it implies a generalisation of how the language is > implemented on a particular platform. I've learned to like > Java because > I've got a beautiful development environment (intelliJ IDEA) and in my > professional life, speed/quality of development is more important than > response times. My clients would prefer to spend more money > on hardware > than on consultancy - who can blame them. > > Steve > > -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:sqlite-users-return-10034-sohara=pivotal-solutions.co. > [EMAIL PROTECTED] > org] On Behalf Of Fred Williams > Sent: 21 January 2006 15:52 > To: [email protected] > Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > I think if you will closely read you own analysis of your efforts you > will realize that all of the "down side" issues you have enumerated > relate directly to the implementation language and not the database or > its structure. In Java there is no such thing as AnythingLite, IMHO. > Java, like so many other languages has grown well beyond its initial > intent, small, simple applets imbedded on a web page. > > With all of our advances in programming we still have not evolved that > "perfect" language, and most likely never will. I spite of what those > "C" guys tell you :-) > > Fred > > > -----Original Message----- > > From: Steve O'Hara [mailto:[EMAIL PROTECTED] > > Sent: Saturday, January 21, 2006 7:37 AM > > To: [email protected]; [EMAIL PROTECTED] > > Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > > > > > > > I did loads of research on this and even tinkered with a c to Java > > converter, which got me a little bit further forward. However, I > > realised that I would be facing a huge effort to create the > code base > > and then have to support it within our projects. So > despite being an > > SQLite zealot, I had to reluctantly nail my colours to one of the > > existing Java tools. > > > > I chose HSQLDB, after trying out most of the others, this > was the only > > one that got close to the file distribution format of SQLite i.e. > > database in a file. It took quite a bit of tinkering to > get the right > > mix of CACHED and MEMORY tables so that performance on start-up was > > good. Also, I had terrible trouble with mass imports causing memory > > (what a surprise - Java) problems and it took a good few runs > > to get it > > to properly index etc. Also, I had to be much more > specific about the > > column definitions than with SQLite, otherwise my database > files grew > > horribly. Also, you can only interact with HSQLDB via > JDBC, not a big > > problem in Java obviously. Performance was nowhere near as good as > > SQLite. > > > > However, the upside is that HSQLDB is free, simple to deploy, has > > standalone/server/servlet/in-memory deployment versions and is > > reasonably perfomant. > > > > Hope this helps, > > > > Steve > > > > p.s. I'd still prefer a Java SQLite but there you are........ > > > > > > > > -----Original Message----- > > From: > > [EMAIL PROTECTED] > > [mailto:sqlite-users-return-9982-sohara=pivotal-solutions.co.u > [EMAIL PROTECTED] > rg] On Behalf Of Ran > Sent: 19 January 2006 14:13 > To: [email protected]; [EMAIL PROTECTED] > Subject: [RBL] Re: [sqlite] Sqlite and Java > > If I am not mistaken, the following thread might be relevant: > http://www.mail-archive.com/[email protected]/msg11005.html > > Ran > > On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > Does anybody here knows something about a port of sqlite to java? > > > > Please, note that I'm not talking about java calling sqlite via JNI, > but > > about a real rewrite of sqlite using java. Obviously, a second step > > would be the writing of a JDBC driver. > > > > Would be useful that port? > > > > Comments? Suggestions? > > > > Thanks to all. > > > > Nilo > > Porto Alegre - Brasil > > > > >
