On Mon, Mar 22, 2010 at 19:47, Thomas Mueller <[email protected]> wrote: >> I was curious to know why you are planning to do this? >> Might I say, I'm a little disappointed? :)
Thanks for asking - I even overlooked that in the changelog. > There are multiple reasons. First, I always wanted to be able to use > H2 without JVM. Not necessarily a fast, but a working version. Earlier > versions of H2 included a native version (compiled using GCJ). > However, there were problems, maybe due to GCJ (not sure) or how I > used it. So I removed the GCJ version. Who cares. I am using H2 because a) I can embed it in my Java apps without loosing platform independence b) it is fast c) small size It seems, both reasons would be destroyed with the C-Version. > The advantages of a native version of H2 are: > * fast startup > * smaller size Anyway, the JVM must be started when my programs start, so nothing gained with the faster startup of H2 - at least not in embedded mode - and in server mode even if my app is a client app only who cares of a few seconds. If the server needs to be restarted already a lot of time lost. And size is already small enough I would say. > * easier to integrate in other languages / platforms / applications This is the only argument that really counts, but: For C ther is SQLite for example, for Scala, Groovy and the like it should not be a problem using H2. Don't know these languages but I heard that they can call Java - and they also use the JVM. > If you look at SQLite, you will see there is a need for that: > https://www.ohloh.net/p/h2database (44 users) > https://www.ohloh.net/p/sqlite (912 users) What I could interpret from this statistic: There are more C-Programmers than Java-Programmers. There are more SQLite users using ohloh.net than H2 users (I didn't know ohloh.net until now for instance). And I even could interpret that there is no need for a H2 in C because there is already SQLite for those who want to use a native C embedded database. > Now, in another project I'm working on (Apache Jackrabbit) there is > also a need for a native version. Not necessarily the whole project, > but probably a subset. For similar reasons than those of H2. For what reasons? Java 7 will even address startup due to increased modularity. > The best language for that is probably C. My idea is to have a > converter from Java to C so that a large part of the code can be > converted to C. I have programmed in C many years ago and I could have returned to C but I have chosen Java for good reasons. One was platform independence and this is what is needed these days because of the slow transition from Windows to other operating systems. > I already wrote a Java to C converter about 10 years ago. This was to > run another Java database (PointBase Micro) on cell phones. The code > was ugly, so I threw it away. But it was working. It was never used in > production for political reasons. Don't know much about cell phones internals - could be that the plain Java version of H2 won't fit there - but here also I have heard that future Java versions are going to address problems on mobile platforms. -- Martin Wildam -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
